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Vorwort 



Dieses Buch behandelt im Rahmen der Reihe BWL im Bachelor-Studiengang den 
betrieblichen Produktionsfaktor Information. Dieser beruht maßgeblich auf Daten. 
Während Software sich mit der Zeit verändert oder ausgetauscht wird, sind die Da- 
ten eine langfristig zu pflegende Ressource jedes Unternehmens. Wie gut Unterneh- 
mensführung gelingt, ist unter anderem von der Qualität der betrieblichen Datenbasis 
abhängig. Diese kann man nicht kaufen wie z.B. Software. 

Deshalb gehört es zu den beruflichen und wissenschaftlichen Qualifikationen 
von Studentinnen* und Studenten der Wirtschaftswissenschaften, die inhaltlichen 
und methodischen Grundlagen von Daten zu lernen. Dies sind die Rolle von Daten 
als Flussgröße in betrieblichen Routineprozessen, ihre Modellierung und Strukturie- 
rung, vor allem aber ihre betriebswirtschaftlichen Inhalte. Auf der Basis von Daten 
lassen sich auch die Funktionen betrieblicher Softwaresysteme am besten verstehen. 

Es scheint an der Zeit, den Produktionsfaktor Information als Grundlage wieder 
in die Betriebswirtschaftslehre aufzunehmen (s. Keinen, 1991). Er fehlt in fast allen 
betriebswirtschaftlichen Einführungen. Das hat zur Folge, dass „Informationen“ oft 
keine erkennbare Basis mehr haben. Dieses Buch kann helfen, für andere betriebs- 
wirtschaftliche Gebiete wie Marketing, Controlling oder Logistik eine Grundlage zu 
schaffen, die nicht selten zu fehlen scheint. Studienanfängern das Gebiet Informati- 
onsmanagement ohne eine solche Grundlage anzubieten hieße sogar, das Dach vor 
den Wänden zu bauen. 

Das Buch vermittelt neben den fachlichen Inhalten mit vielen praktischen Bei- 
spielen vor allem Konzepte zu Daten, unabhängig von Produkten. Technische Eragen 
werden ausgeklammert, wo immer möglich. Programmieren wird hier nicht gelehrt. 
Als Darstellungsmittel wird UML 2.0 verwendet, eine recht neue, international ge- 
normte grafische Sprache. Mit ihr lassen sich alle graphischen Modelle des Buches 
ausdrücken, das sind (Geschäfts-)Prozesse und Datenstrukturen. Ich denke, dass ich 
sie „praxisorientiert“ darstellen konnte, wobei mir dabei viele Jahre Industrieerfah- 
rung nützlich waren. 



* Die Leserinnen mögen mir nachsehen, dass sie in diesem Buch nicht jedesmal explizit 
genannt werden. Sie sind selbstverständlich mit diesem Text angesprochen. 
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Vorwort 



Das Buch bietet Stoff und Ansatzpunkte für verschiedene Veranstaltungen, z.B. 
Kurse wie Einführung in die Wirtschaftsinformatik, Informationswirtschaft oder 
Grundlagen der Betriebsinformatik im Grundstudium. Ebenso ist es geeignet als 
Grundlage eines entsprechenden Moduls im Hauptstudium des Bachelor oder als 
Aufbaumodul in einem Master-Studiengang. Dort wird man sicher einige hier be- 
wusst einfach gehaltene Notationen formal vertiefen. 

Da mit UML in den Wirtschaftswissenschaften Neuland betreten wird, sind de- 
taillierte Erläuterungen der Notation ins Internet verlagert worden. Dort hnden sich 
auch Aufgaben (www. wiwi .uni-bielefeld. de/~spitta). Kritik und An- 
regungen werden unter thSpitta@wiwi.uni-bielefeld.de erbeten. 



Bielefeld, im Oktober 2005 



Thorsten Spitta 
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Einführung 



Dieses Buch behandelt die Grundlagen des betrieblichen Produktionsfaktors Infor- 
mation. Im Folgenden wird erläutert, warum man einen solchen Faktor in der heu- 
tigen Zeit neben den in der Betriebswirtschaftslehre üblichen annehmen muss, die 
mit Arbeitskraft (auch Personal), Betriebsmittel und Werkstoffe (auch Material) an- 
gegeben werden. Man kann Information nicht einfach als Betriebsmittel abtun, da es 
viele spezielle Entscheidungs- und Gestaltungsprobleme für diesen Produktionsfak- 
tor gibt. Von der Lösung dieser Probleme soll hier die Rede sein. 

Information, zunächst intuitiv benutzt, ist nicht an Computer oder andere infor- 
mationsverarbeitende Maschinen gebunden. Sie ist notwendiger Bestandteil aller ar- 
beitsteiligen Produktionsprozesse und kann auch mit Bleistift und Papier oder mit 
Zeichen auf Tontafeln repräsentiert oder mündlich übermittelt werden. Sie spielt al- 
lerdings durch die Entwicklung der Computertechnik eine immer größere Rolle in 
unserem Wirtschaftsleben. Hierbei wird Information notiert und gespeichert. Notier- 
te Information, bei denen der Datenträger keine Rolle spielt, nennt man Daten. Sie 
sind eine wichtige Ressource jedes Unternehmens, unabhängig davon, ob gekaufte 
oder selbst entwickelte Software eingesetzt wird. 

Um die Rolle der Information zunächst auf einfache Weise zu verdeutlichen, 
betrachten wir einen Handwerksbetrieb. 

Nur ein Meister alleine ohne jedes Personal kann einzelne Produkte ohne Informa- 
tion herstellen. Er muss dann Niemandem aufschreiben, was zu tun oder welches 
Material zu beschaffen ist. Er benötigt allerdings Wissen, um in vertretbarer Zeit zu 
einem sinnvollen Ergebnis zu kommen. Dieses Wissen muss er irgendwann einmal, 
evtl, in der Lehre, erworben und später verfeinert und erweitert haben. Erstellt er 
sein Produkt arbeitsteilig, muss er seinem Lehrling oder Gesellen in einer Sprache 
und Schrift, die dieser versteht, notieren, was zu tun ist. Tut er dies nicht, wird er 
sich wohl kaum für längere Zeit vom Arbeitsort entfernen können, die „Teilung“ der 
Arbeit wäre also höchst einseitig. 

Wir sehen bereits an diesem simplen Beispiel die Rolle der Information zu Zwecken 
der Kommunikation und der Erinnerung, unter anderem, um Produkte repetitiv und 
arbeitsteilig hersteilen zu können. 
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Will der Meister ein alleine hergestelltes Produkt genau gleich noch einmal an einem 
anderen Ort bauen, wird er dies wiederum nur mit Hilfe von Daten tun können, 
nämlich einer Konstruktionsskizze. Die Repräsentation der Daten ist in diesem Fall 
belanglos. Es genügt ein Pappkarton, den der Meister eher zur Hand haben wird als 
ein Blatt Papier. 




2003) 



Abb. 1.1 zeigt betriebliche Funktionen, wie sie bereits in einem Handwerksbetrieb 
anzutreffen sind, als Fluss von Produktionsfaktoren und Geld. Das von Domschke 
und Scholl im Grundaufbau übernommene Bild wurde für unser Thema modifiziert, 
indem das Rechnungswesen durch eine umfassendere Funktion Information ersetzt 
und die Flüsse nach Typen unterschieden wurden. Es zeigt wesentliche Aspekte, 
die in diesem Buch herausgearbeitet werden sollen. Wir wollen die betrieblichen 
Funktionen unter dem Blickwinkel der sich zwischen ihnen bewegenden Flüsse von 
Material oder immateriellen Leistungen, Finanzmitteln und Information betrachten, 
wobei Informationsflüsse in Abb. 1.1 nicht überall eingezeichnet sind. Die von dem 
Knoten Information ausgehenden Informationsflüsse deuten die vielfältigen Bezie- 
hungen in alle Bereiche und zwischen ihnen nur informell an. Explizit eingezeich- 
net ist die Beschaffung von Informationen aus Märkten durch die entsprechenden 
Eachfunktionen und die von Beschaffung und Absatz ausgehende Abwicklung von 
Zahlungsvorgängen durch die Eunktion Einanzen. 

An einigen Stellen benutzen wir statt Funktion die Begriffe Bereich oder Organi- 
sationseinheit. Dies soll nicht etwa bedeuten, dass nur funktionsorientiert organisiert 
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würde, wohl aber, dass sich die grobe funktionale Gliederung aus Abb. 1.1 in den 
meisten Unternehmen auch organisatorisch festmachen lässt. 

Nicht jede Flussgröße ist an jedem Übergang gleich stark beteiligt. Bei produ- 
zierenden Unternehmen sind im oberen Teil des Bildes Material und Arbeit die do- 
minierenden Flussgrößen des sog. Leistungsbereiches. Bei Dienstleistern besteht das 
Produkt aus Arbeitsleistungen, während die interne Produktionsfunktion nur rudi- 
mentär oder gar nicht existiert, z.B. bei einer Beratung. Die zwischen Unternehmen 
und Umwelt fließenden Informationen sind Daten, von denen einige sogar justizia- 
bel sind. Sie heißen Bestellung, Auftrag und Rechnung. Sie wurden allerdings in Abb. 
1.1 aus Gründen der Übersicht nicht eingezeichnet. Wie man diese und andere Da- 
tentypen modelliert und welche Rolle sie in betrieblichen Routineprozessen spielen, 
wird in Kapitel 3ff. ausführlich behandelt. Hier werden zunächst die fünf Funktionen 
aus Abb. 1 . 1 erläutert: 

Die Beschaffung (auch Einkauf) sorgt für die Einsatzstoffe des Produktionspro- 
zesses oder direkt zu verkaufende Produkte (sog. Zukauf). Diese Beschaffungsgüter 
nennen Material . Logisch werden, wie in Abb. 1.1 gezeigt, auch Arbeitskräfte 

„beschafft“ (s. Schierenbeck, 2003, Abb. 112). Dies ist aber in keinem Unterneh- 
men Aufgabe des Beschaffungsbereiches, sondern obliegt einem Personalbereich. 
In diesem Bereich sind soziale Erfahrungen und juristische Kenntnisse erforderlich. 
Aufgabe der Beschaffungsfunktion ist jedoch häufig, eine Bedarfsermittlung durch- 
zuführen, sowie die kostengünstigsten Bestellzeitpunkte und deren Losgrößen (op- 
timale Bestellmengen) zu ermitteln. Alle diese Berechnungen basieren auf Daten. 
Weiterhin gehört zu dieser Eunktion regelmäßig die Verantwortung für das Materi- 
allager. Auf die Beschaffung von Information gehen wir weiter unten ein. 

Die Produktion stellt in einem Wertschöpfungsprozess durch Kombination von 
Arbeitskraft, Betriebsmitteln, Material und Information Produkte her (s. etwa Kistner 
& Steven, 2002, Kap. 2; Schierenbeck, 2003, Kap. 5; Töpfer, 2005, Kap. E.III). Dies 
können materielle oder immaterielle handelbare Waren sein, die durch die Punktion 
Absatz zu verkaufen sind, aber auch Dienstleistungen, die nur beim Kunden erbracht 
werden können, etwa bei einem Handwerksbetrieb. Die traditionellen betriebswirt- 
schaftlichen Probleme der Produktion stammen aus dem eigentlichen Produktions- 
prozess und dessen Planung, z.B. Reihenfolge- und Kapazitätsbelegungsprobleme 
oder die Beziehung zwischen Einsatzmenge und optimaler Ausbringung (Reichwald 
& Dietel, 1991 oder Kistner & Steven, 2002). Die Punktion Produktion ist in In- 
dustrieunternehmen der Ort der stärksten technischen Kompetenz, weshalb dort re- 
gelmäßig auch die Teilfunktion Produktentwicklung (auch Konstruktion) angesiedelt 
ist. 

Der Absatz (auch Vertrieb oder Marketing) hat entweder bereits produzierte Pro- 
dukte zu verkaufen oder Beziehungen zum Absatzmarkt aufzubauen und zu pflegen, 
um Aufträge für noch zu produzierende Produkte zu gewinnen. East immer findet 
man auch eine ausgewiesene Teilfunktion Marketing, die den Markt zu beobachten, 
Marktdaten zu beschaffen und zu analysieren hat, Produktideen generiert und auch 
rückläufige Daten wie Reklamationen bearbeiten sollte. Die Punktion Absatz wird 
üblicher Weise gleichzeitig im Betrieb wahrgenommen (Vertriebs-Innendienst) und 
im Markt (Außendienst). Der kostengünstige Einsatz eines großen, in verschiede- 
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nen Regionen tätigen Außendienstes erfordert leistungsfähige Softwaresysteme zur 
Planung, Steuerung und Kontrolle, die schlecht standardisierbar sind. Auf sie und 
andere Anwendungssysteme werden wir in Kapitel 7 elngehen. 

Die Finanzen werden von einer gut abgegrenzten Organisationseinheit verwal- 
tet, meist Finanz- und Rechnungswesen genannt. Sie zerfällt in die nach innen ge- 
richtete Betriebs- und die nach außen gerichtete Finanzbuchhaltung (internes und 
externes Rechnungswesen), sowie eine Einheit, die sich um das Kapital und die Li- 
quidität kümmert. Das Rechnungswesen ist zwar nicht das Informationssystem der 
Unternehmung, wie man noch gelegentlich liest, aber ohne Zweifel ein sehr wichti- 
ges. Für Geldflüsse im Sinne von Zahlungsvorgängen zwischen Umwelt und Unter- 
nehmen ist grundsätzlich nur der Finanzbereich zuständig. Wenn man die Mitarbeiter 
in ihrer Rolle als (private) Haushalte sieht, an die eine Vergütung fließt, gibt es inner- 
halb eines Unternehmens keine Geldflüsse. Statt dessen gibt es umfassende Informa- 
tionsflüsse sowohl über anstehende Zahlungsvorgänge als auch umfassende Kosten- 
Informationen für praktisch alle betrieblichen Funktionen. Finanzinformationen sind 
sehr wesentliche Entscheidungsgrundlagen für routinemäßige, taktische und strate- 
gische Entscheidungen. Die Rolle und Funktionsweise des Anwendungssystems Fi- 
nanzbuchhaltung als Datensammler werden wir ebenfalls ln Kapitel 7 transparent 
machen. 

Die Funktion Information war historisch im Rechnungswesen angesiedelt, ist 
aber heute eine getrennte Einheit mit den Bezeichnungen Informatik oder Organi- 
sation / Datenverarbeitung. Sie hat die Aufgabe, Information bereitzustellen, nicht 
aber sie zu beschaffen. Die drei in Abb. 1 . 1 mit Märkten verbundenen Funktionen 
beschaffen ihre externen Informationen selbst. Die extern beschafften Informationen 
haben allerdings nur einen sehr kleinen Anteil am Volumen betrieblicher Daten ins- 
gesamt. Das Gros betrieblicher Daten entsteht im Rahmen betrieblicher Vorgänge 
innerhalb des Unternehmens in den Fachfunktionen. Die jeweiligen Organisations- 
einheiten verantworten die Korrektheit der Daten, die sie erzeugen. 

Die Einheit Informatik betreibt die maschinellen Teile des Faktors Information, 
die Informationstechnik (IT), und stellt das methodische Wissen zur Durchführung 
von Projekten und zur Modellierung von Daten und Prozessen zur Verfügung. Sie 
verantwortet eine sichere Speicherung korrekter Unternehmensdaten und bietet den 
Fachfunktionen und der Unternehmensleitung geeignete Systeme zur Verbesserung 
von Informationen an. Sie sorgt dafür, dass alle Material- und Geldflüsse in Abb. 1.1 
von den richtigen Informationen begleitet werden, wobei es hier Überschneidungen 
mit den Ansprüchen der betrieblichen Funktion Controlling geben kann (vgl. Jahnke, 
2005). 

Darüber hinaus ist es eine originäre Aufgabe jeder Unternehmensleitung, beson- 
ders wichtige Informationen aus der Umwelt des Unternehmens selbst zu beschaffen. 
Diese Art von Informationen ist nur selten in Form von Daten repräsentiert. Dennoch 
wäre die Führung eines heutigen Unternehmens ohne eine explizit organisatorisch 
verankerte Informationsfunktion unmöglich. Auf einen kurzen Nenner gebracht, ist 
sie für heutiges Wirtschaften selbst im kleinen Rahmen unentbehrlich, so dass wir 
im folgenden Kapitel zeigen können: 
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Es gibt zwar keine Recherche im Internet und keinen Blick auf Börsenkurse, 
vor allem aber keine Warenlieferung oder Zahlung ohne Information in 
der Form von Daten. 

Dies mag einleitend genügen, um zu begründen, dass die Rolle des Produktions- 
faktors Information zu wichtig ist, als dass man seine Modellierung und Handha- 
bung der Intuition überlassen könnte. Die Fälle weltweit bekannter Managementfeh- 
ler sind Legion (Neumann, 1995),^ bei denen die Intuition hochrangiger Manager 
beim Faktor Information mit kostspieligen Folgen versagt hat. Dies zeigt nicht nur 
das Beispiel Toll Collect, bei dem Ende 2003 ein Milliarden schweres Versagen von 
Industrie- und Bürokratie-Managern zu konstatieren war (FAZ, 2004). Weitere, nicht 
so bekannte Beispiele sind: 

o 1995 konnte der neue Flughafen in Denver/USA erst 16 Monate verspätet in Betrieb ge- 
hen, weil Hardware und Software für die Gepäcksteuemng „billig“ vergeben und völlig 
dilletantisch und funktionsunfähig realisiert waren. Die Opportunitätskosten bis zur Inbe- 
triebnahme des Flughafens betmgen laut Neumann (1995) 3,2 Mrd. US $. 
o 1992 entstanden beim Versagen der Informationsfunktion im Versand eines Massenher- 
stellers, der an Supermärkte des Lebensmittelhandels lieferte (250 Mio € Jahresumsatz), 
wegen eines Serverausfalls durch drei Stunden Versandausfall Absatzverluste von 500.000 
€. Die Geschäftsleitung hatte dem IT-Chef einen redundanten Server zur Absicherung 
solcher Ausfälle im Wert von 50.000 € verweigert, 
o Derselbe Massenhersteller mit täglich 500.000 verkauften Artikeln und einem flächende- 
ckenden Vertrieb war in den 90er Jahren trotz eine Marktanteils von 57% durch „Sparsam- 
keit“ im Informationsbereich zum Saniemngsfall geworden. Die Geschäftsleitung hatte 
die Bedeutung der Pflege und Struktur der Artikelstammdaten für die aufwändige Ver- 
triebslogistik nicht erkannt. 

Trotz der allgegenwärtigen Existenz ist betriebliche Information nicht etwa unstruk- 
turierbar. In Form von Daten hat sie klare, methodisch begründete Formen. Diese 
lassen sich für ein Industrieunternehmen, natürlich auch für eine Bank oder ein Ver- 
sicherungsunternehmen, semantisch allgemein gültig als Referenzmodelle darstel- 
len. Als zeichnerische Notation wird der seit 1997 gesetzte internationale Standard 
UML (Unified Modelling Language) in der Fassung 2.0 benutzt (Object Management 
Group, 2005). UML ist eine grafische Sprache mit umfassenden Möglichkeiten, von 
denen wir hier nur einen kleinen Teil in vereinfachter Form anwenden. Dieser reicht 
aus, um alle Graphiken dieses Buches in einer einheitlichen Notation zu verfassen. 
Nur einige wenige informelle Skizzen werden aus didaktischen Gründen von dieser 
Regel ab weichen. 

In diesem Buch sollen schwerpunktmäßig Inhalte und Struktur betrieblicher Da- 
ten geklärt werden. Dazu betrachten wir zunächst betriebliche Funktionen und Pro- 
zesse (Kapitel 2), in denen ein Teil dieser Daten entsteht. Die Prozesse interagieren 
überwiegend über die Daten betrieblicher Vorgänge, die die dominierende Flussgrö- 
ße bei Routineprozessen darstellen. Will man jedoch über Daten genauer sprechen, 
sie sogar selbst modellieren, ist es unumgänglich, sie sehr elementar zu betrachten 

* aktuell von 1985 bis 2004 mit mnd 2000 dokumentierten Fällen unter: 
http : / / catless . ncl . ac.uk/Risks (ACM Usenet) 
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1 Einführung 



und einige wenige Grundlagen zu lernen, die nicht in der Mathematikausbildung 
vermittelt werden. Daher geht Kapitel 3 ganz „tief unten“ auf Zeichen, Codes und 
Ähnliches ein, ohne die man das Grundkonstrukt von Daten, den Datentyp, nicht 
verstehen kann. Dies ist keine Technik, sondern Mengenlehre, die in einem für uns 
ungewohnten Gewand „daher kommt“. Nur auf dieser Basis können wir betriebliche 
Kommunikation und Information so präzise definieren, wie das beim Phänomen In- 
formation möglich ist. Dies geschieht in Kapitel 4. Erst dann ist der Boden bereitet, 
um in Kapitel 5 die Inhalte betrieblicher Daten darzustellen. 

In Kapitel 6 wird die Struktur der Daten besprochen, auch bekannt als Daten- 
modellierung. Kapitel 7 gibt einen Überblick über Anwendungssysteme des Indus- 
triebetriebs, zu denen Kapitel 8 den organisatorischen Bezug der Datenverantwor- 
tung behandelt. Kapitel 9 schließlich gibt einen Ausblick auf die absehbare Zukunft, 
die bereits begonnen hat. Die Auszeichnungssprache XML notiert Daten in ande- 
rer Form als allgemein üblich und erweitert so das Spektrum der automatisierten 
Verwendung von Daten. XML ermöglicht insbesondere eine einfachere maschinelle 
Kommunikation zwischen Unternehmen, als dies traditionelle Techniken zulassen. 

Der scheinbare Bruch in der Gliederung nach Kapitel 2 hat seine Ursache dar- 
in, dass zwar heute jedes betriebswirtschaftliche Buch Grundlagen der Mathematik 
voraussetzen kann, die Informationswirtschaft diese aber erst selbst vermitteln muss. 
Deshalb gehen im Gegensatz zum sonstigen Aufbau des Buches die Kapitel 3 bis 4 
bottom-up vor. Sie müssen die nötige Basis für die Kapitel 5ff. schaffen. 

Notationen, z.B. zu UML, Fragen und Aufgaben finden sich im Internet (Spitta, 
2005). 
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Betriebliche Funktionen und Prozesse 



Zu Beginn hatten wir mit Abb. 1 . 1 eine idealisierte Gesamtsicht von Unternehmen 
skizziert, die betriebliche Funktionen durch die Flussgrößen Geld, Information, Ma- 
terial und Arbeit verknüpfte. Wir werden diese Funktionen weiter präzisieren, indem 
wir die Flussdarstellung aus Abb. 1.1 grafisch verfeinern. Dies wird zur expliziten 
Darstellung von Informationen führen, so dass wir Prozessdarstellungen erhalten, die 
besser als die funktionale Sicht zeigen, wie Funktionen über Informationen intera- 
gieren. Die Informationsflüsse werden noch in Lenkungs- und Leitungsflüsse zerlegt, 
um eine präzise Vorstellung von dem in der Literatur oft nur vage umrissenen Begriff 
Geschäftsprozess zu erhalten. 

Die Sicht dieses Kapitels auf Unternehmungen weicht von der üblicher betriebs- 
wirtschaftlicher Lehrbücher ab. Während jene Methoden und Theorien liefern, die 
überwiegend bei strategischen und taktischen Entscheidungen zum Ansatz kommen, 
stehen hier operative Entscheidungen im Vordergrund. Entscheidungen in diesem 
Bereich werden oft nicht explizit gefällt, sondern durch faktisches Handeln oder 
auch Unterlassen. Um solche Situationen überhaupt erkennen zu können, benötigen 
wir Erklärungs- und Referenzmodelle für das operative Geschehen. Erst durch diese 
wird es möglich, betriebliche Abläufe zu verstehen. Die hier verwendete grafische 
Sprache UML sollte intuitiv verständlich sein, kann aber auch im Internet (Spitta, 
2005) nachgeschlagen werden. Dort werden die Knoten- und Kantentypen der Gra- 
phen erläutert. 

Am Ende des Kapitels müsste der Leser eine grobe Vorstellung davon haben, wie 
ein Betrieb dynamisch „funktioniert“ und gelernt haben, dass und wie Daten hierzu 
maßgeblich beitragen. 



2.1 Funktions-Sicht 

Abb. 1 . 1 hat eine traditionelle Sicht betrieblicher Funktionen gezeigt. Die drei Funk- 
tionen Produktion, Absatz und Finanzen bildeten bereits 1954 die Gliederung eines 
Klassikers der Betriebswirtschaftslehre, den drei Bänden von Gutenberg (1983). Die 
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Beschaffung, auch Bereitstellungsplanung genannt, kommt dann in inzwischen eben- 
falls verbreiten Lehrbüchern hinzu (z.B. Bea, Dichtl & Schweitzer, 2002; Schieren- 
beck, 2003; Wöhe, Kaiser & Döring, 2002). Seit ca. 1990 wurde auf Grund industri- 
eller Entwicklungen erkannt und an einigen Stellen auch in der Literatur umgesetzt, 
dass es vor allem im Bereich des Materialflusses eine Querschnittfunktion gibt, die 
es verbietet, rein funktional zu denken. Dies nannte man in Anlehnung an das militä- 
rische Vorbild Logistik (Pfohl, 2004). Damit wurde eine Funktion gebildet, die dem 
Materialfluss folgt. 

Auch dies war nicht neu. Seit 1982 heißt eines des ältesten Software-Module des 
System R (realtime) der Fa. SAP material management (MM). Kern des Systems 
ist eine integrierte Sicht auf alle Materialdaten und die daraus abgeleiteten Vorgänge 
wie Bestellungen, Wareneingänge, Einlagerungen und Buchungen im Produktions- 
prozess und in der Finanzbuchhaltung. Trotzdem stellte es sich als schwierig heraus 
(Verantwortungs- = Machtbereiche, mangelnde Überschaubarkeit in Folge ungeeig- 
neter Daten und Ähnliches), die Vision der prozessorientierten Organisation umzu- 
setzen. Es enststanden Wortgebilde wie Beschaffungs-Logistik, Produktions-Logistik 
und Absatz-Logistik (Domschke & Scholl, 2003, 135), die die alte Funktionsgliede- 
rung wieder aufleben ließen. Wir werden zeigen, dass der Intergrationsgedanke rein 
funktional nicht Fuß fassen kann, weil er nicht operational ist, dass sich aber über 
Daten eine nachvollziehbare Integration ergibt, die nur intuitiv schwer zu erkennen 
ist. 

2.1.1 Funktionaler Überblick 

Die Funktionen werden zunächst traditionell betrachtet, um daran einige Aussagen 
über funktionale Zerlegungen festzumachen. Tabelle 2.1 zeigt diese Sicht um eine 
Ebene, in den Funktionen Absatz und Finanzen um zwei Ebenen (Einrückungen) 
verfeinert. 



Tabelle 2.1. Verfeinerungen der betrieblichen Grundfunktionen 



Beschaffung 


Produktion 


Absatz 


Finanzen 


Marktbeobachtung 

Bestelldisposition 

Bestellbearbeitung 

Bestellüberwachung 

Wareneingang 

Lagerverw./MAT 


Entwicklung 

Kalkulation 

Produktionsplanung 

Fertigungsbelegung 

Fertigungssteuerung 

Qualitätskontrolle 

Instandhaltung 


Marketing 

Absatzplanung 

Verkauf 

AngebotsErstellg 

AuftragsEing. 

AuftrBearbeitg 

Lagerverw./FF 

Versand 

Fakturierung 

Statistik 


Kapitalbeschaffung 

Gehaltsabrechnung 

Buchhaltung 

Debitoren 

Kreditoren 

Anlagen 

Jahresabschluss 

Controlling 

Kostenrechnung 

Budgetierung 

Berichtswesen 
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Die Funktionen und deren Bezeichnungen werden in konkreten Fällen sowohl 
betriebs- als auch branchenspezifisch variieren. Z.B. werden die Spezialisierungen 
Produktions- und Fertigungs- weitgehend synotnym verwendet. Auch wird es Fir- 
men geben, in denen die Buchhaltung die Fakturierung durchführt oder das Control- 
ling auch die Vertriebsstatistiken im Rahmen des Berichtswesens erstellt. 

Die Funktion „Statistik“ im Bereich Absatz wird bei einem Zulieferer des Lebens- 
mittelhandels sehr sinnvoll, bei einem Automobil-Zulieferer dagegen nicht zweck- 
mäßig sein, da jener nur fünf Kunden hat, ersterer aber 25.000 Lebensmittelfilialen 
versorgen muss. 

Weiterhin taucht die Funktion Lagerverwaltung zweimal auf. Offensichtlich geht es 
hier um verschiedene Rollen des gleichen Gegenstandstyps, im Beispiel um einge- 
kaufte Ware (Material) und um verkaufsfähige Ware {Fertigfabrikat). Wenn man 
davon absieht, dass eine Personalfunktion und die Informationsfunktion hier nicht 
ausgewiesen sind, dürfte Tabelle 2.1 für viele Unternehmen zutreffen, unabhängig 
davon, wie die Arbeitsteilung im konkreten Einzelfall organisiert ist. 

Die in Tabelle 2.1 gezeigten weiteren Verfeinerungen der Teilfunktionen Ver- 
kauf, Buchhaltung und Controlling in Ebene 2 präzisieren die übergeordneten Be- 
griffe. Sie zeigen, wie man alle Funktionen der Ebene 1 im Prinzip verfeinern könnte. 
Man würde dabei aber immer betriebsspezifischer werden und hätte wenig allgemei- 
ne Erkenntnis gewonnen. Zumindest kommt man dem Verständnis, wie ein Betrieb 
in der Folge seiner Funktionen „funktioniert“ , damit nicht näher, weil die Funkti- 
onssicht statisch ist. Dies ändert sich, wenn wir uns um eine dynamische Sicht in der 
Form von Prozessen bemühen, d.h. um den Zusammenhang der Funktionen. Jedes 
Unternehmen, auch jede staatliche Organisation, wäre ein Chaos, wenn im Routine- 
betrieb jede Funktion mit jeder anderen kommunizieren müsste. Statt dessen ist die 
Kommunikation für Routineprozesse straff geregelt und spielt sich durch die Über- 
mittlung streng typisierter Daten ab. Man nennt diese auch „ Vorgänge“. 

2.1.2 Aufgaben, Funktionen und Verrichtungen 

Wenn Menschen zielgerichtete Tätigkeiten ausüben, spricht man von Aufgaben. 
Nach Ferstl & Sinz (2001) lassen sich zwei Aufgabentypen unterscheiden, Trans- 
formations- und Entscheidungsaufgaben. Erstere zerfallen noch in Aufgaben ohne 
und mit Speicher. Dies zeigt Abb. 2.1. 

Eall a) wäre etwa das Ermitteln des Umsatzes eines Quartals mit den Daten aller 
Rechnungen als Input. Es werden also keine originär neuen Daten erzeugt. Fall b) 
erzeugt neue und verändert bestehende Daten. Dies wäre z.B. eine Lagerzu- oder ab- 
gangsbuchung, die neue Daten erzeugt und den Lagerbestand ändert. Fall c) schließ- 
lich beschreibt eine Entscheidungssituation, in der eine Eührungs- oder Zielgröße 
das Ergebnis mit bestimmt, etwa die Einplanung eines Produktionsauftrages, der auf 
Grund eines Kundenauftrags einen vorgegebenen Endtermin hat. 

Von c) nach a) nimmt die Automatisierbarkeit der Aufgaben zu. Aufgaben, die 
automatisierbar sind, nennt man häufig Funktionen oder auch Operationen. Ebenso 
werden Funktion und Aufgabe synonym benutzt, wie wir es hier tun. Wir greifen den 
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Input 



^ > Aufgabe J 



Output 



a) reine Transformation; Output= f(lnput) 




b) Transformation auf Basis eines Speichers 



Zielgrößen 




c) Entscheidungsaufgabe 

Abb. 2.1. Aufgabentypen bei der Informationsverarbeitung (Ferstl & Sinz, 2001, 31) 



Unterschied aber in Kapitel 7 wieder auf, wenn es um automatisierte Aufgaben geht. 

Ein weiteres, 1960 von Kosiol eingeführtes Synonym für Funktion ist Verrichtung. 

Ein Vorgang besteht nicht nur aus Daten (s. oben), sondern ist eine Teilaufgabe im 

Routinebetrieb. 

Zusammenfassung Abschnitt 2.1 

o Man kann Funktionen bis zu einzelnen Tätigkeiten schrittweise verfei- 
nern. Dies ist eine statische Sicht. 

o Es gibt keine allgemein festgelegten Begriffe für betriebliche Teilfunk- 
tionen, statt dessen diskursspezifische Synonyme, 
o Bei der Wahrnehmung betrieblicher Aufgaben entstehen Daten oder es 
werden Daten als Entscheidungsgrundlage benutzt, 
o Transformationsaufgaben von Daten sind tendenziell automatisierbar. 



2.2 Prozess-Sicht 

Wir betrachten zunächst Prozesse aus Funktionen mit einer anonymen Flussgröße 
Information, danach Flüsse aus Folgen von Funktionen und Daten. Am Schluss wird 
eine Verallgemeinerung der Flussgrößen eingeführt. 





2.2 Prozess-Sicht 
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2.2.1 Prozesse aus Funktionen 

In Abb. 2.2 ist die Funktion aus Abb. 1.1 grafisch verfeinert. Sie zeigt mehrere 

allgemeine Phänomene: 

o Durch die Verfeinerung werden die Nachbarfunktionen zur Umwelt des Teilsys- 
tems. Sie sind aber keine Märkte, sondern Akteure. Dies drücken wir durch ein 
spezialisiertes Ohjekt-Symhol aus. 

o Eine Verfeinerung muss exakt in den übergeordneten Graphen passen. Nur so 
erhält man Schnittstellen-, das sind zwischen Funktionen oder mit der Umwelt 
ausgetauschte Daten. 

o Als Flussgröße zwischen den Funktionen dominieren Informationen, da auch die 
Materialflüsse von Informationen hegleitet werden. 




Abb. 2.2. Die Funktion Absatz mit Informations- und Materialfluss 



Abb. 2.2 umfasst Funktionen des Absatzes, wie sie in Unternehmenstypen Vor- 
kommen, die täglich viele Liefer-Transaktionen auf Basis eines Fertigfabrikatela- 
gers durchführen müssen. Die Teilfunktionen Marketing und Absatzplanung haben 
Schnittstellen zu den beiden vorgelagerten Funktionsbereichen. Die Marktbeobach- 
tung der Funktion Beschaffung (s. Tabelle 2.1) versucht, Zukaufwünsche zu erfüllen, 
die ihr die Absatzplanung übermittelt. Die Produktionsplanung prüft die Fertigungs- 
kapazitäten und errechnet an Hand von Durchlaufzeiten Fiefertermine. Die Entwick- 
lung der Funktion Produktion versucht, die Wünsche des Marketing umzusetzen und 
wird sie gemäß Tabelle 2.1 auch kostenmäßig kalkulieren {Kostenträgerrechnung). 
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Wem die Bezeichnungen der Funktionen etwas sagen, der kann nach dem Mus- 
ter von Ahb. 2.2 eine erste Vorstellung von den Material- und Informationsflüssen 
innerhalb der betrieblichen Grundfunktionen bekommen. Durch die Prozessdarstel- 
lung werden Zusammenhänge der Teilfunktionen offen gelegt, wenn man die übrigen 
Funktionen analog zu Absatz verfeinert. Wir haben damit ein erstes Indiz dafür, dass 
überwiegend Informationsflüsse die betrieblichen Abläufe bestimmen. Dies wird in 
der nächsten Verfeinerungsstufe noch deutlicher werden, wenn wir die Informatio- 
nen explizit als Datentypen abbilden. 

Um die Allgemeingültigkeit des Beschreibungsansatzes zu zeigen, ist in Abb. 2.3 
die alternative Absatzfunktion für einen Handwerksbetrieb gezeigt (vgl. Kapitel 1). 




Abb. 2.3. Variantes Flussmodell der Funktion Absatz für Einzelfertiger 



Der Handwerker wird kaum ein Fertigfabrikate-Lager und schon gar keinen Ver- 
sand haben, ebenso keine Absatzplanung. Dafür wird man bei ihm eine präzisere 
Verfeinemng der Funktion Verkauf erwarten, denn hier liegt seine Haupttätigkeit: 

Ein Handwerker ist ein Einzelfertiger, der ständig neue Aufträge aquirieren und ver- 
suchen muss, dauerhafte Kundenbeziehungen zu möglichst großen Auftraggebern 
aufzubauen und zu pflegen. Dies trifft aber auch auf eine Werft oder ein großes Bau- 
unternehmen zu. 

Der Verkauf muss für den Unternehmenstyp Einzelfertiger bereits in Ebene 1 
in Eorm von zwei wichtigen Teilfunktionen sichtbar werden, der Angebotserstel- 
lung, die intensive Verhandlungen mit dem Kunden einschließt, und den für Produk- 
tion und Beschaffung wichtigen dispositiven Vorbereitungen nach einem Auftrags- 
eingang. Die allgemeine Struktur bleibt im Prinzip bestehen, wenn auch nicht in den 
Details. Die Produktion eines Handwerkers bestünde dann aus den Punktionen Pro- 
duktionsplanung, Vorfertigung in der Werkstatt und Leistungserbringung an der Bau- 
stelle (s. auch weiter hinten Abb. 2.7). In der Systemumwelt ist mit [Kunde] gezeigt. 
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dass spätestens ab dem Zeitpunkt der Angebotserstellung der anonyme Markt für den 
Vorgang Auftragsabwicklung ein „Gesicht“ bekommt, und zwar durch Beziehungen 
zu konkreten Objekten dieser Umwelt, über die Daten gesammelt werden. Identifi- 
zierbare Subjekte aus dem Markt werden aus Sicht des Unternehmens zu Akteuren, 
hier die Kunden. 

Der Ablauf in Abb. 2.2 verdeckt allerdings einen wichtigen Aspekt der tatsäch- 
lichen Abläufe, indem er von der Zeit abstrahiert. Während die Funktionen Marke- 
ting und Absatzplanung in längere Produktzyklen eingebunden sind, beginnt bei der 
Funktion Verkauf der Routinebetrieb von vielleicht hunderten von Aufträgen, die 
täglich abzuwickeln sind. Genau diese werden fakturiert und nur aus ihnen speist 
sich die direkt angeschlossene Statistik als wichtiges Führungsinstrument des Ab- 
satzbereiches. Dies und eine Präzisierung durch Daten stellen wir im Folgenden vor. 

2.2.2 Datenflüsse 




Abb. 2.4. Teilprozesse verschiedener Frequenz 



Wir haben bereits starke Indizien dafür, dass überwiegend Informationsflüsse die 
betrieblichen Abläufe bestimmen. Dies wird deutlicher, wenn wir die Informationen 
explizit als Datentypen abbilden. Wenn man die Flüsse zwischen den Funktionen 
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benennt, spricht man von Datenflüssen. Wenn wir darüber hinaus noch die Zeit in 
die Prozess-Sicht mit einbeziehen, und zwar das Maß 



Frequenz 



AnzahlEreignisse 

Zeiteinheit 



dann müssen wir den Prozess Absatz aus Abb. 2.2 in zwei Flüsse trennen. Beim Ein- 
zelfertiger (Handwerker, Schiffbau) ist das nicht der Fall, da die Frequenz der Tä- 
tigkeiten beim Absatz übereinstimmt. Wir erhalten zwei zeitlich zu unterscheidende 
Teilprozesse, die Abb. 2.4 zeigt. 



Unterstellen wir, dass ein Lebensmittel-Lieferant hitzeemplindliche Waren wie Scho- 
kolade herstellt. Dann wird er jährlich zwei Teilprozesse zum Aufstellen eines Ab- 
satzplanes haben, Sommer und Winter genannt. Bestimmte Schokoladensorten kön- 
nen im Sommer nicht verkauft, müssen aber im Sommer für den Verkauf im Winter 
produziert werden. 

Das gleiche Bild hätten wir bei einem Hersteller von Textilien, der ebenfalls zwei 
jahreszeitlich bedingte Saisonwechsel bewältigen muss. Man nennt den Prozess dort 
Kollektion. 



Auch an Abb. 2.4 lassen sich allgemeine Aspekte zeigen: 

o Prozesse Zeichen sich durch ein Start-Ereignis {auslösendes E.) und ein End- 
Ereignis {abschließendes E.) aus, die explizit erkennbar sein müssen (Termin 
oder Datenzustand). 

o Auch Prozesse verschiedener Frequenzen sind durch Funktionen miteinander 
verknüpft, die sich nicht konkreten Prozessen zuordnen lassen (im Beispiel Sta- 
tistik). 

o Informationsflüsse werden durch Daten repräsentiert (in den Grafiken Rechtecke 
für Datentypen). 

Die Flüsse lassen sich noch stärker verallgemeinern. 



2.2.3 Lenkungs- und Leistungsflüsse 

Nach Ferstl & Sinz (2001) lassen sich die Flüsse Material, Arbeit (Dienstleistung) 
und Geld aus Abb. 1.1 zu Leistungsflüssen zusammenfassen. Informationen erhalten 
dann die Rolle von Lenkungsflüssen . 

Die von Ferstl und Sinz stammende Abb. 2.5 der Routineprozesse im Indus- 
trieunternehmen zeigt die beiden Flusstypen Leistungs- und Lenkungsflüsse, wobei 
die Bezeichnungen der starken Kanten des Graphen Objekte der gegenständlichen 
Welt (Rohstoffe, Produkte, Geld) und die der gestrichelten dünnen Kanten die der 
informationeilen Welt in Form von Datentypen (mehr hierzu in Kapitel 3) darstellen. 
Man sieht, dass die Funktionsgliederung verschwindet. In Abb. 2.5 wurden bis auf 
wenige Ausnahmen die von Ferstl und Sinz gewählten Bezeichnungen beibehalten. 
Dies verfolgt den Zweck, die studentischen Leser dieses Buches frühzeitig auf die 
Vielfalt von Synonymen bei betrieblichen Funktions- und auch Datenbezeichnungen 
einzustellen. Die wichtigsten hier zu sehenden Datentypen werden wir in Kapitel 5 
präzisieren, indem wir ihre Beziehungsgeflechte und Merkmale offen legen. 




2.3 Funktionsübergreifende Prozesse 
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Abb. 2.5. Lenkungs- und Leistungsfiüsse im Industrieunternehmen (Ferstl & Sinz, 2001, 43) 



Natürlich sind die hier gezeigten Datentypen nicht alle Elemente der Lenkungs- 
flüsse, sondern nur die der operativen Prozesse. Viele der für die Unternehmens- 
führung relevanten Lenkungsflüsse haben fallweisen Charakter. Sie sind auch kei- 
nesfalls immer in Form von Daten repräsentiert. Es gibt jedoch auf höherer Ebe- 
ne standardisierte Datentypen, die als Führungsinformationen für die verschiedenen 
Management-Ebenen eine wichtige Rolle spielen. Mehr folgt hierzu in Kapitel 6. 

Zusammenfassung Abschnitt 2.2 

o Die funktionale Sicht ist als Grundlage für Prozesse nur bedingt taug- 
lich, da sie zu stark an statischen Strukturen orientiert ist. 
o Die Führung der Routineprozesse im Unternehmen erfolgt durch Infor- 
mation in der Form von Daten. 

o Die Funktionsgliederung löst sich bei Prozessbetrachtungen auf. 



2.3 Funktionsübergreifende Prozesse 

Obwohl Prozesse die funktionale Gliederung durchbrechen, stellt sie eine wichtige 
Orientierung dar. Die grafische Norm UML ermöglicht es, dies sichtbar zu machen. 
Davon machen wir Gebrauch, indem wir bei wichtigen Prozessen die betrieblichen 
Grundfunktionen zeigen. 

2.3.1 Innerorganisatorische Prozesse 

Innerorganisatorische Prozesse haben keine direkte Verbindung zur Systemumwelt. 
Einer der wichtigsten dieser Prozesse im Industriebetrieb, von dem der Unterneh- 
menserfolg maßgeblich abhängt, geht von der Funktion Forschung und Entwicklung 
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aus (F&E). In nicht forschenden Unternehmen* fällt die erste Teilaufgahe weg, die 
zweite ist aber immer noch sehr gewichtig. Nur mit ständigen Produktinnovationen 
können Unternehmen auf Dauer Erfolg haben, seien sie in der Pharma-, Automobil- 
oder Textilbranche tätig (Gemünden, 2002). 



Produktentwicklung 




Abb. 2.6. Der Prozess Produktentwicklung {Produktgestaltung) 



Es gehört seit langem zu den Grundaussagen der Betriebswirtschaftslehre, dass 
die Produktgestaltung ein maßgeblicher Parameter des absatzpolitischen Instrumen- 
tariums ist (Gutenberg, 1983). Zusammen mit der Sortimentsgestaltung bildet sie 
einen Bestandteil des sog. Marketing-Mix. Dabei stehen die wichtigsten Einfluss- 
größen der Produktgestaltung zueinander im Zielkonflikt, so dass es sich verbietet, 
eines der folgenden Atribute alleine zu „optimieren“: Schnell, gut, billig. Ein viel 

* Forschung heißt, ergebnisoffen zu arbeiten, d.h. es kann sich auch kein oder ein völlig 
unerwartetes Ergebnis einstellen. Unbekannt ist das Ob überhaupt. Entwicklung heißt, ein 
im Prinzip gelöstes Problem in eine technische Lösung umzusetzen. Unbekannt ist das Wie, 
nicht das Ob. 
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verwendeter Aphorismus zu dieser „Optimierung“ ist, dass man sich maximal zwei 
davon aussuchen könne. Gelegentlich wird auch diskutiert, den Prozess Produktent- 
wicklung aus dem Unternehmen auszulagern (sog. Outsourcing). Dies kann gefähr- 
lich sein, da man die Produktentwicklung als sog. Kernprozess eines Unternehmens 
nicht aus der Hand gehen sollte. In Kernprozessen ist das Wissen eines Unterneh- 
mens besonders konzentriert. 

Das Charakteristische für unsere Prozessbetrachtung ist, dass der Prozess F&E 
in der Pharma- oder Automobilindustrie Jahre benötigt. In der Bekleidungsindustrie 
ist das zwar nicht so, denn dort gibt es im Jahr mindestens zwei Kollektionen, al- 
lerdings muss eine Kollektion auch dort sehr diszipliniert ablaufen, da die Frequenz 
2/Jahr beträgt. Schlägt dieser Prozess auch nur einmal fehl, kann dies das Aus für 
das Unternehmen bedeuten. 

Abb. 2.6 zeigt den Prozess der Produktentwicklung in einer groben Form. Fs 
würde an dieser Stelle jeden Rahmen sprengen, ihn im Detail darzustellen. Jedoch 
sei gerade Studenten der Wirtschaftswissenschaften dringend geraten, sich eine Vor- 
stellung von der wirklichen Komplexität dieses Prozesses zu machen, den Scheer 
unter der Überschrift Leistungsgestaltungsprozesse der Technik und des Marketing 
im Verbund umfassend so dargestellt hat, dass dies auch von Nicht-Technikern ver- 
standen werden kann (Scheer, 1997, Teil C). Hintergrund ist vor allem, dass es eine 
Fülle interdisziplinärer Kriterien gibt, die sich in den Anforderungen an ein neues 
Produkt niederschlagen. Sie sind in Abb. 2.6 als Grundlage der Anforderungsermitt- 
lung in Form einer Notiz (s. Spitta, 2005) mit aufgenommen. Der Synchronisations- 
balken zu Beginn des Bereiches Produktion bedeutet ein logisches UND zwischen 
den Ausgängen. 

Dieser Ablauf lässt sich nicht mehr einzelnen Funktionsbereichen aus Tabelle 
2.1 zuordnen, sondern berührt viele Funktionen. Zwar ist der Bereich Produktion 
auf Grund seines technischen Wissens maßgeblich beteiligt, aber ebenso wichtig 
sind Erfordernisse des Marktes aus dem Absatzbereich und finanzielle Rahmenbe- 
dingungen. Die mit der Nachsilbe -entscheidung in Abb. 2.6 gezeigten „Funktionen“ 
sind mehrtägige Sitzungen umfassend besetzter Gremien aus allen Unternehmens- 
bereichen. Deren Ergebnisse wiederum werden von der Unternehmensleitung selbst 
entschieden. Man sieht, dass der Prozess zwei mögliche Ergebnisse mit definierten 
Zuständen haben kann. 

Andere innerorganisatorische Prozesse finden sich z.B. innerhalb des Vertriebs- 
Außendienstes oder der Produktion. Letztere können vor allem bei „billiger“ Aus- 
landsproduktion sehr komplex und störanfällig werden, wenn man den Faktor In- 
formation vernachlässigt. So ist das lange Zeit sehr gefeierte Konzept Just-in-Time 
(Zulieferung erst zum Zeitpunkt der Montage) sehr empfindlich, da es keine Puffer 
mehr gibt („Das Lager ist die Autobahn“ ). Auch aus diesem Beispiel lassen sich 
wichtige Verallgemeinerungen ableiten: 

o Wieder entstehen Daten, allerdings keine, die Routinevorgänge mit täglicher Fre- 
quenz beschreiben wie in Abb. 2.4, sondern dauerhafte Grunddaten. Artikel 

(auch Teile genannt) und Stücklisten sind die wichtigsten Daten eines Industrie- 
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Unternehmens, da sie fast alle Vorgänge im Betrieb steuern. Sie werden in Kapitel 
5 sehr detailliert behandelt. 

o Daten sind ebenso unverzichtbar wie Funktionen, werden aber schlechter wahr- 
genommen. Dies liegt vermutlich in der starken Kopplung von Funktionen und 
Organisation, in der man lebende Akteure sieht. Diese verstehen es, die Rele- 
vanz der von ihnen wahrgenommenen Funktion (= Arbeitsplatz und/oder Kom- 
pentenzbereich) deutlich zu machen, während Daten passive Objekte sind, 
o Betrieblich relevante Prozesse verlaufen quer zu einer Funktionsgliederung, die 
häufig auch die Organisationsstruktur bildet. 

2.3.2 Geschäftsprozesse 

Es besteht kein Konsens in der Betriebswirtschaftslehre, ob Prozesse, wie am Bei- 
spiel der Produktentwicklung gezeigt, Geschäftspwzess genannt werden sollten oder 
nicht und ob man den Begriff überhaupt braucht (Gaitanides, 2004). Manche fordern, 
dass hierzu nur solche Prozesse zählen, die in der Umwelt des Unternehmens begin- 
nen oder enden und an der Wertschöpfung beteiligt sind (Vossen & Becker, 1996; 
Stahlknecht & Hasenkamp, 2005). 

Der Bezug auf die Umwelt ist sicher ein Indiz dafür, dass die Prozesse wichtig 
sind. Allerdings dürften auch die (innerbetriebliche) Produktentwicklung oder die 
Transportvorgänge von dezentralen Produktionsstätten zu einem zentralen Versand 
keine unwichtigen Prozesse sein. Scheer (1997) nennt in seiner umfassenden Darstel- 
lung des Industriebetriebs genau zwei Prozesse, die alle o.g. Bedingungen erfüllen, 
die Beschaffung und den Vertrieb. Mertens (2004) nennt noch den Kundendienst. Als 
dritten grundlegenden Prozess nennen beide die Produktgestaltung. 

Bei Einzelfertigern verschmelzen die beiden Abläufe Beschaffung und Vertrieb 
zu nur einem Prozess Auftragsabwicklung (Mertens, Bodendorf, König, Picot, Schu- 
mann & Hess, 2005), der im Groben gleichermaßen für einen Handwerksbetrieb mit 
wenigen und für eine Werft mit tausenden von Arbeitskräften gilt. Diesen Ablauf 
zeigt Abb. 2.7. 

Die Auftragsabwicklung wird bei einem konkreten Unternehmen detaillierter dar- 
gestellt werden müssen. In Abb. 2.7 hat sie jedoch die abstrahierende Eorm eines 
Referenzmodells, der für ein allgemeines Verständnis besser geeignet ist als eine 
konkrete Darstellung (s. hierzu Becker & Delfmann, 2004). Der Prozess berührt al- 
le in Tabelle 2. 1 genannten Punktionsbereiche, indem er im Absatzbereich beginnt, 
mit der Beschaffung und Produktion fortfährt und abschließend im Pinanzbereich 
mit dem Erlös endet. Abweichungen vom Normalablauf, etwa Lieferverzögerungen 
oder Zahlungsverzug mit Mahnungen, ergeben nur weitere Details, die keine neu- 
en Erkenntnisse bringen. Bezogen auf einen Handwerksbetrieb würde der Ablauf 
bedeuten: 

Ab dem Start-Ereignis [Interessent meldet sich] folgen die Tätigkeiten Angebots- 
erstellung, Auftragsbearbeitung, Bestelldisposition, Vorfertigung und die eigentli- 
che Fertigung, bevor die Rechnung gesteht wird. Mit der Angebotserstellung hat 
der Handwerker bereits eine genaue Planung seiner Produktion durchgeführt, sonst 
könnte er nicht kalkulieren. Bei Neubauten wird ihm regelmäßig ein detailliertes 
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Auftragsabwicklung 




Abb. 2.7. Der (Geschäfts-)Prozess Aufiragsabwicklung bei Einzelfertigung 
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Leistungsverzeichnis als Angebot abverlangt, das juristisch die Grundlage seines 
Festpreises ist. Das Angebot enthält die Soll-Daten des Flandwerkers, gegen die er 
die Ist-Daten aus den Leistungsnachweisen seiner Mitarbeiter stellt, um zu ermitteln, 
ob er mit dem Auftrag Gewinn oder Verlust macht. Das End-Ereignis des Prozesses 
ist die Zahlung der Rechnung durch den Kunden. 

Auch hier sind allgemeine Punkte und Ergänzungen in der grafischen Notation her- 
vorzuheben: 

o Der Geschäftsprozess beginnt und endet bei konkreten Akteuren des Absatz- 
marktes. Im Fall der Einzelfertigung werden der Absatz- und der Beschaffungs- 
markt synchron angesprochen. Wir modellieren nicht das Handeln dieser Akteu- 
re, sondern nur die Repräsentation der Handlungen in Form (passiver) Daten, 
o Die Auftragsabwicklung ist ein typischer Routineprozess, der durch Daten ge- 
steuert wird. Diese Daten heißen Vorgangsdaten {hier Aufirag, Bestellung, Rech- 
nung). 

o Vorgangsdaten bilden inner- und außerbetriebliche Schnittstellen, das sind Da- 
tenstrukturen, die regelmäßig zwischen Akteuren ausgetauscht werden (hier Auf- 
tragsbestätigung und Rechnung). 

o Es gibt über die Auftragsabwicklung hinaus noch finanzwirtschaftliche oder per- 
sonalwirtschaftliche Geschäftsprozesse (z.B. Kreditgewährung oder die Suche 
nach Führungskräften), die aber keine Routineprozesse sind. Sie finden im Ge- 
gensatz zu Routineprozessen üblicher Weise nicht öffentlich statt, sondern eher 
diskret, unter Beteiligung sehr weniger Akteure. Dem gegenüber ist die Ein- 
stellung von Mitarbeitern ein personalwirtschaftlicher Routineprozess und wohl 
auch ein Geschäftsprozess im oben verstandenen Sinne, 
o An Routineprozessen sind viele Akteure beteiligt. Dies sind in Industrieunterneh- 
men Prozesse, die den Materialfluss vorbereiten oder steuern. Sie werden auch 
Logistikprozesse genannt (Pfohl, 2004; Scheer, 1997). 
o Methodisch gibt es keinen Unterschied zwischen inner- und außerbetrieblichen 
Prozessen. 

Eine Zerlegung der Auftragsabwicklung in zwei zueinander asynchrone Abläufe 
Beschaffung und Vertrieb entsteht bei Serien- und Massenfertigern, bei denen eine 
Lagerhaltungsfunktion hinzu kommen muss, um die beiden Abläufe zu synchroni- 
sieren. Material- und Warenbestände sind Puffer, die unterschiedliche Frequenzen 
von Abläufen ausgleichen. Die Beschaffung verläuft mit anderen Frequenzen und 
anderen Mengen als der Verkauf. Dies zeigt Abb. 2.8. Man sieht die beiden Teilpro- 
zesse, die erst beendet sind, wenn die Geldflüsse erfolgreich waren. Beide Prozesse 
sind Mengen- und Werteflüsse, wobei der Wertefluss durch Daten ausgelöst wird. Da- 
gegen ist der (innerbetriebliche) Produktionsprozess ein reiner Mengenfluss, selbst- 
verständlich begleitet von Daten. Weiterhin ist zu beachten, dass die Beziehungen 
zur Umwelt jetzt nicht mehr auf anonyme Märkte bezogen sind, sondern auf die Ak- 
teure Lieferant und Kunde. Aus Gründen der Übersicht wurden die Datentypen nicht 
explizit dargestellt. Sie werden aber detailliert in den Kapiteln 3 und 5 besprochen. 

Abb. 2.8 beschreibt die wichtigsten Teilfunktionen der Routineprozesse industri- 
eller Produktion und Distribution (vgl. Tabelle 2.1). Läger sind jetzt als materielle 
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Ressource ausgewiesen. Hierdurch wird ihre Pufferfunktion auch grahsch sichtbar. 
Bei einem Auftragsfertiger wird sie kundenbezogen stattfinden, wobei auf vorhan- 
dene Standard-Aggregate zurückgegriffen wird. Dies wäre der Betriebstyp Einzel- 
fertiger mit Vorfertigung. Es wird auch auf der Basis von Rahmenverträgen in Serie 
gefertigt, z.B. von Automobil-Zulieferern. Weiterhin wird kundenanonym auf La- 
ger gefertigt und vom Lager verkauft. Dies würde auf einen Hersteller von Unter- 
haltungselektronik zutreffen. Als Letztes bleibt die kundenanonyme, saisonbeding- 
te Vorfertigung. Sie würde für Schokoladen- oder Bekleidungshersteller gelten, die 
während einer Saison die Ware für die nächste Verkaufssaison produzieren. 

2.3.3 Transaktionen 

Transaktionen sind ein sehr wichtiges Phänomen aus der Datenbanktechnik, das in 
der Informatik seit etwa 1960 bekannt ist. Es bezeichnet einen Prozess, bei dem Da- 
ten von einem konsistenten, gespeicherten Zustand über Zwischenzustände in einen 
neuen, wieder konstistenten Zustand überführt werden. Ausgangs- und Endzustand 
sind permananent gespeicherte Daten (s. Abb. 2.1). Dem gegenüber ist der Haupt- 
speicher eines Computers ein temporärer Speicher. Dessen Zwischenzustände gelten 
während der Bearbeitung der Daten als inkonsistent. Eine Transaktion darf deshalb 
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nur vollständig oder gar nicht ausgeführt werden. Dies hat z.B. bei Buchungen von 
Daten eine große praktische Bedeutung (s. auch Wedekind, 1979). 

1975 hielt dieser Begriff in Form der Transaktionskostentheorie auch Einzug in 
die Wirtschaftswissenschaften (Kistner & Steven, 2002, 314f), allerdings mit ver- 
änderter Semantik. Es ging um unternehmensübergreifende Geldgeschäfte oder Wa- 
renbewegungen und deren Kosten. Dies würde nicht zu unserem Thema gehören, 
wenn es nicht notwendig wäre, sich des ursprünglichen Transaktionsbegriffs zu ent- 
sinnen. Die hier aufgezeigten Geschäftsprozesse sind nichts Anderes als lang lau- 
fende Transaktionen im ursprünglichen Sinne. Ein Geschäftsvorfall wird nur dann 
kostengünstig ablaufen, wenn er den geplanten Verlauf nimmt und vor allem erfolg- 
reich zu seinem definierten Ende kommt. Erst dann gilt er aber nach dem datenbank- 
orientierten Transaktionsbegriff als konsistent. 

Die Beschreibung eines Geschäftsprozesses ist der Typ oder auch das Muster des 
Prozesses, das konkrete Exemplar (ein bestimmter Auftrag, die gerade laufende Be- 
stellung) ist die Transaktion. Das auslösende Ereignis eröffnet, das abschließende be- 
endet sie. Alle Zeit verbrauchenden Operationen, die vom typisierten Normalablauf 
abweichen, erhöhen auch bei innerbetrieblichen Prozessen die Transaktionskosten. 
Solche Operationen sind etwa Rückfragen, Wiederholungen bei falschen oder mit 
Mängeln behafteten Lieferungen oder Mahnungen. Die Prozesskostenrechnung ver- 
sucht, die Transaktionen kostenmäßig transparent und damit die Prozesse messbar 
zu machen (vgl. Ewert & Wagenhofer, 2005). 

Ziel der Informationsfunktion eines Unternehmens muss es sein, den Informa- 
tionsfluss der Transaktionen so reibungslos wie möglich zu gestalten. Reibungen 
haben eine zeitliche, aber auch eine qualitative Dimension. Während die Prozess- 
zeit noch intuitiv gesteuert werden kann, wird bei der Prozessqualität Wissen über 
die Korrektheit und Einfachheit von Daten benötigt. Dies wird in Kap. 5 ausführlich 
behandelt. 

Zusammenfassung Abschnitt 2.3 

o Prozesse sind Abläufe, die durch Ereignisse ausgelöst und durch ab- 
schließende Ereignisse beendet werden. Abläufe sind Teile davon in 
Form von Folgen sequentieller und paralleler Funktionen (synonym Ak- 
tivitäten), die unter Anderem Daten erzeugen oder verändern. Ggf. gibt 
es Verzweigungen auf der Basis von Entscheidungen. 
o Funktionen sind in Abläufen durch Daten verbunden, die entweder al- 
leinige Flussgröße oder begleitende Flussgröße für Material- und Geld- 
flüsse sind. Daten dienen als „Spuren“, die betriebliche Prozesse neben 
dem Ergebnis der Wertschöpfung Unterlassen, 
o Wenn die Routineprozesse eines Betriebes analysiert und notiert wer- 
den, bekommt man eine Vorstellung davon, wie der Betrieb funktioniert, 
o Die Routineprozesse bilden geschäftliche Transaktionen, die zu einem 
hohen Anteil störungsfrei abgeschlossen werden sollten. 
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2.4 Wiederholung 

• Flüsse von Funktionen führen in der Verfeinerung auf die Flussgröße Daten. 

• Daten sind als konkret konstruierbare Typen benennbar, z.B. Artikel oder Bestel- 
lung. 

• Wichtige, für die Wertschöpfung grundlegende Flüsse heißen Prozesse, die 

- Ereignisse als Auslöser haben, 

- konkrete Daten erzeugen oder verändern, 

- mehrere betriebliche Funktionsbereiche berühren, 

- mit konkreten, meist als Daten repräsentierten Ereignissen abgeschlossen 
werden, 

- im Inneren Verzweigungen mit operativen Entscheidungen sowie parallele 
oder alternative Tätigkeiten aufweisen können. 

• Solche Prozesse werden auch Geschäflsprozesse genannt. Sie sind ein Schlüssel 
zur Beurteilung der Effizienz der Routinevorgänge eines Unternehmens. 

• Daten der operativen Elüsse bestehen überwiegend aus Vorgangsdaten. 
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Daten 



über den intuitiven und dann oft folgenschweren Umgang mit der Informationsfunk- 
tion und Daten wurde schon in Kapitel 1 gesprochen. Hierzu ein Beispiel über dessen 
Wurzeln: 



y = ax + b (3.1) 

ist bekanntlich die Gleichung einer Geraden zwischen den Koordinaten x und y mit 
den Koeffizienten a und b, welche die Steigung und Lage der Geraden beschreiben. 
Jeder Abiturient kennt das aus der Schulmathematik. Also kennt das auch fast je- 
der Manager. Alle Elemente der Gleichung werden Variablen genannt, was für die 
Zwecke des Rechnens auch ausreicht. Für betriebliche Zwecke würde man noch die 
„Information“ gehen, dass y der Preis und x die AbsatzMenge sei, falls der Zusam- 
menhang der beiden Größen denn linear ist. Ein Mathematiker würde wohl noch 
hlnzufügen, dass alle Variablen der Gleichung aus der Menge M der reellen Zahlen 
stammen, also nicht ganzzahlig sein müssen. Insofern prägt die Schulmathematik 
unser intuitives Verständnis von Daten, das offenbar auf Zahlen beschränkt ist. Das 
Phänomen Information können wir so aber nicht erklären. Dies dürfte mit dem Hin- 
weis auf ein Telefongespräch offensichtlich sein, denn selbstverständlich kann dort 
Information fließen, in der vielleicht auch Zahlen mitgetellt werden, aber auch Vie- 
les, das sich nicht in Zahlen ausdrücken lässt. 

Wir benötigen Grundbausteine für Information, die sowohl die Welt der Zahlen 
als auch die der sonstigen Zeichen umfassen. Diese Grundbausteine werden im Fol- 
genden eingeführt, und zwar Zeichen, Alphabete, Texte und Daten. Darauf aufbauend 
können wir im nächsten Kapitel Information erklären und uns abschließend kurz an 
den schillernden Begriff Wissen wagen. Bis dahin müssen wir Information intuitiv 
benutzen. 



3.1 Zeichen und Alphabete 

In der westlichen und der nahöstlichen (arabischen) Welt werden Zeichen als Ele- 
mente von Schriftsprachen benutzt. Für unsere Zwecke genügen zunächst die Zei- 
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chen der lateinischen Schrift, ergänzt um die arabischen Ziffern, mit denen wir rech- 
nen. Wir haben damit drei kleine Zeichenvorräte, die großen und die kleinen Buch- 
staben, sowie die Ziffern, die wir zu einem größeren zusammenfassen. Wir notieren 
dies in Tabelle 3.1 als Zeichenvorrat mit seinen Bestandteilen, wobei Kardinalität 
die Anzahl der Elemente einer Menge bedeutet. 



Tabelle 3.1. Zusammensetzung eines Zeichenvorrates aus Teilmengen 



Teilmenge Zeichenvorrat Kardinalität 



Dezimalziffern = 


(0, 1,2 


,..9) 


10 


Große Buchstaben = 


(A, B, . 


•Z} 


26 


Kleine Buchstaben = 


{a, b, .. 


z) 


26 


Zif f ern_und_Buchstaben = 


{0,1,.. 


z} 


62 



Das klingt plausibel, hat aber Implikationen, die offen gelegt werden müssen. Wir 
haben nämlich in allen vier Tabellenzeilen, nicht nur bei den Buchstaben, jeweils 
ein Alphabet definiert und die Teilalphabete zu einem neuen zusammengefügt. Ein 
Alphabet ist nach DIN 44300 ein geordneter Zeichenvorrat ^ A = {Zi,Z 2 , ..Z,,} mit 
Zi < Z 2 < .. < Z„, also eine Menge, für die eine Ordnung definiert ist. Jedes Eolge- 
zeichen gilt als größer als der Vorgänger. 

Wir können zwar die Teilalphabete intuitiv lesen, ohne dass alle Elemente aufge- 
führt sind, das Alphabet Ziffern_und_Buchs haben können wir aber nur mit 
Kenntnis der Teilalphabete richtig interpretieren. Alphabete können beliebige Zei- 
chenfolgen sein, wie etwa 

Sonderzeichenz = {§, !, ", $, %, &, (, ), /, =}. 

Dies sind offensichtlich nicht alle Sonderzeichen, sondern nur die Untermenge, die 
auf einer PC-Tastatur über den Ziffern steht, wenn auch in anderer Reihenfolge. 
Auch das Alphabet der Dezimalziffern ist auf der Tastatur anders definiert, näm- 
lich als {1, 2, ..9, 0}. Die Beispiele der Sonderzeichen und Ziffern zeigen, dass die 
Eestlegung, welche Zeichen in ein Alphabet gehören und was als die richtige Reihen- 
folge gilt, willkürlich ist und sich nicht aus irgendwelchen „Gesetzen“ ableiten lässt. 
Eestlegungen, die allgemeine Gültigkeit haben sollen, sind Vereinbarungen zwischen 
Akteuren des Wirtschaftslebens. Sie heißen Standard. 

Wir können jetzt weitere wichtige Begriffe für erste Grundbausteine von Daten 
als schriftlich fixierte Informationen definieren. Ein Wort ist eine Eolge von Zeichen 
aus einem definierten Zeichenvorrat, deren Ende durch ein vereinbartes Zeichen an- 
gezeigt wird. Am häufigsten wird hierfür das Leerzeichen verwendet, vor allem in 
natürlichen Sprachen. Satzzeichen wie Komma oder Punkt gelten ebenfalls als Ende- 
zeichen für ein Wort. Ein Text ist eine Eolge von Wörtern, zuzüglich der vereinbarten 
Trennzeichen. 

* Informatik und Linguistik benutzen für die Zwecke der Konstruktion formaler Sprachen 
einen anderen Alphabet-Begriff 
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Die Ordnungsrelation von Alphabeten ist von großem praktischem Wert, weil 
sie es erlaubt, eine allgemein verstandene Ordnung in Texte als wichtige Grundbau- 
steine von Informationen zu bringen, insbesondere sie nach einem Ordnungsbegriff 
zu sortieren. Jeder kennt solche Ordnungen aus Telefonbüchern oder Verzeichnissen 
auf Computern. 

Der Name Z i f f ern_und_Buchs taben war nicht zufällig mit Unterstrichen 
geschrieben worden. Er sollte als ein Wort gelten. Der Name iJohn wäre in der eng- 
lischen oder deutschen Sprache kein gültiges Wort, wohl aber auf einem Computer 
als Dateiname. Überzeugen Sie sich durch Anlegen einer Datei mit diesem Namen 
selbst, dass sie vor jeder Datei, die mit ’A’ beginnt, zu sehen ist, falls „alphabetisch“ 
sortiert angezeigt wird. Dies gilt nicht für alle Betriebssysteme. 

Für Texte mit mehr Informationen, als sie Namen beinhalten können, müssen 
mehr Zeichen erlaubt sein als unser Alphabet aus Tabelle 3.1 kennt, selbst wenn 
wir die oben einführten Sonderzeichenz noch hinzufügen. Zwei solcher Al- 
phabete heißen EBCDI (Extendet Binary Coded Decimal Interchange) und ASCII 
{American Standard Code for Information Interchange). EBCDI hat die Kardinalität 
2^ = 128, erlaubt also 128 Zeichen, ASCII erlaubt die doppelte Menge von Zei- 
chen, also 2* = 256. Im älteren Alphabet EBCDI sind noch immer weltweit riesige 
Datenbestände gespeichert. Das Alphabet ASCII prägt alle heutigen mittleren und 
kleinen Computer, insbesondere die sog. PC. Für unsere Zwecke sind im Moment 
nur zwei Dinge wichtig, spezielle Zeichen und die Aufteilung in die erste und die 
zweite Hälfte des Alphabets ASCII. 

Die ersten 32 Zeichen von ASCII sind sog. nicht druckbares Zeichen, die der 
Steuerung von Texten auf Ausgabemedien dienen. Das sind vor allem Bildschirme 
und Drucker. Das bekannteste Zeichen ist LE (line feed), das für einen Zeilenvor- 
schub sorgt. Es ist ehemaligen Benutzern der mechanischen Schreibmaschine als 
großer Hebel noch sehr gegenwärtig. Dieses Teilalphabet heißt Steuerzeichen. 

Die zweite Eigenschaft von ASCII hat eigentlich auch historische Ursprünge, 
ist aber für jegliche weltweite Kommunikation gerade heute sehr wichtig. Der ur- 
sprüngliche ASCII-Code enthielt nur 128 Zeichen wie sein damaliger Konkurrent 
EBCDI. Er wurde später erweitert. Die Teil-Aphabete heißen Lower ASCII und Up- 
per ASCII. Nur Lower ASCII wird international identisch verstanden. Also sollten 
Internet- Adressen nur aus diesen Zeichen bestehen und nur Texte aus diesen Zei- 
chen können ohne spezielle Programme gelesen werden. Von Upper ASCII gibt es 
kulturspezifische Varianten. Unsere Umlaute und ’ß’ sind z.B. nur in Upper ASCII 
enthalten. 

Zusammenfassung Abschnitt 3.1 

o Ein Alphabet ist ein Zeichenvorrat, für den eine Ordnung definiert ist. 

o Disjunkte (sich vollständig unterscheidende) Alphabete lassen sich zu 
größeren Alphabeten verketten. 

o Ein Wort ist eine identifizierbare Folge von Zeichen aus einem Alphabet. 

o Ein Text ist eine Menge von Wörtern, für die bestimmte Trennzeichen 
dehniert sind. 
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o Ein Text ist im Normalfall nur über einem Alphabet definiert.^ 



3.2 Codes 

Nun soll die Bedeutung von Codes und danach von Zahlensystemen als besonders 
bedeutsamen Codes geklärt werden. Auch EBCDI und ASCII werden Codes ge- 
nannt, wobei mit Code meist ein standardisiertes Alphabet gemeint ist. 256 Zeichen 
(ASCII) reichen trotz alternativer Varianten der oberen 128 Zeichen bei weitem nicht 
aus. Upper ASCII ist lediglich eine Behelfslösung, denn die alternativen oberen Ta- 
bellen von ASCII verursachen viele praktische Kommunikationsprobleme. Eür ei- 
ne wirkliche Internationalisierung braucht man ein Alphabet, das auch Zeichen von 
Sprachen abbildet, die über weit mehr Buchstaben verfügen als das lateinische Al- 
phabet. Auch gibt es eine Vielzahl anderer Zeichenvorräte etwa der Mathematik oder 
Chemie, die ebenfalls darstellbar sein sollten. Zur Lösung dieses Problems wurde ein 
neues, internationales Alphabet mit dem Namen UNICODE geschaffen, das in der 
Grundstufe 2^® = 65.536 und in einer bereits definierten Ausbaustufe 2^^ « 4 Milli- 
arden Zeichen aufnehmen kann. 

Natürlich bedarf es einer Ordnung, die über die Reihenfolge der Zeichen hin- 
ausgeht, um ein so großes Alphabet benutzbar zu machen. Diese Ordnung ist die 
Aufteilung in Teilalphabete, die in Tabellen dargestellt sind. Sie enthalten je nach 
Thema drei bis 48 Spalten und jeweils genau 16 Zeilen, sind also entsprechend den 
Anforderungen des codierten Problembereichs kleiner oder größer (s. Tabelle 3.2). 
Im Gegensatz zu den alternativen Tabellen des Upper ASCII ist der Zeichenvorrat 
von UNICODE groß genug, um eine eindeutige Ordnung zu erlauben. Die Ord- 
nungszahl eines Codes ist ein Index, über den man Zeichen ansprechen kann und 
ein Platzhalter für das Zeichen, mit dem es sich rechnen lässt. Der Index wird beim 
UNICODE auch für die Nummerierung der Tabellen benutzt. So wären die Ord- 
nungszahlen des letzten Elementes der ersten und des ersten Elementes der zweiten 
Code-Tabelle, also die Elemente 128 und 129 des UNICODE-Aphabetes: 

128io < 129io = OOTTjg < 0080ig 

Die Ordnungszahlen sind allerdings nicht wie beim ASCII-Code dezimal angegeben, 
sondern hexadezimal, wie dies auch beim älteren EBCDI-Code üblich war. 0080ie ist 
die hexadezimal geschriebene Nummer der zweiten Tabelle und die Ordnungszahl 
des ersten Zeichens dieser Tabelle. Bevor wir das hiermit berührte Thema Zahlen- 
systeme weiter verfolgen, sollen einige Beispiele in Tabelle 3.2 illustrieren, welch 
unterschiedliche Problembereiche in UNICODE geregelt sind.^ 



^ Fügt jemand in einen lateinisch geschriebenen Text griechische Worte in Originalschrift 
ein, weitet er sein Alphabet um die griechischen Buchstaben aus. Tut er dies auf einem 
Computer, muss das benutzte Alphabet die griechischen Buchstaben enthalten. Andernfalls 
ist für diese Buchstaben die Operation Schreiben nicht definiert. 

^ Genaue Informationen erhält man über http : / /wmi . Unicode . org. 
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Tabelle 3.2. Beispiele für Tabellen des internationalen Alphabets UNICODE 



Tab-Nr 


Tabellen-Name 


Inhalt 


0000-007F 


CO Controls and Basic Latin 


Die ersten 128 ASCII-Zeichen 


0080-00FF 


CI Controls and 


die meisten Zeichen aus Upper ASCII 




Latin- 1 Supplement 


und zusätzliche Steuerzeichen 


0370-03FF 


Greek and Coptic 


griechisch und koptisch 


0400-04FF 


Cyrillic 


kyrillisch (russisch-serbische Schrift) 


OFOO-OFFF 


Tibetan 


tibetisch 


13A0-13FF 


Cherokee 


die Schrift der Cherokee-Indianer 


25A0-25FF 


Geometrie Shapes 


geometrische Grundformen, z.B. Kreise 
und Dreiecke 


2200-22FF 


Mathematical Operators 


verbreitete mathematische Symbole, 
z.B. y, d oder ^ 


2800-28FF 


Braille Patterns 


Blindenschrift 


4DC0-4DFF 


Yijing Hexagram Symbols 


Chinesiches Zeichensystem für den 
Wandel der Natur 


E0000-E007F Tags 


Auszeichnungen für HTML, XML u.ä. 
Sprachen 



Zusammenfassung Abschnitt 3.2 

o Die heute verbreiteten Codes, ASCII und EBCDI, genügen den Anfor- 
derungen einer internationalen Kommunikation nicht. Hierfür ist als sehr 
viel mächtigerer Code UNICODE definiert, 
o Wenn jedes Zeichen in einem Code eindeutig innerhalb des Alphabets 
ist, kann man mit den Zeichen und Worten über die Ordnungszahlen 
rechnen. 



3.3 Zahlensysteme 

Zahlensysteme sind in unserem Kontext Zeichenfolgen eines Alphabets, die wir Zah- 
len zuordnen und mit denen wir Rechenoperationen durchführen können, etwa die 
Addition oder Multiplikation. Damit verknüpfen wir über eine definierte Operation 
zwei Zeichenketten zu einer neuen Zeichenkette, denn Zahlen bestehen aus mehreren 
Zijfern, bei denen der Wert einer Ziffer von der Stelle abhängt, an der sie innerhalb 
der Zahl geschrieben ist. 

Stellenwertsysteme sind Zahlensysteme, bei denen Operationen, die einen grö- 
ßeren Wert ergeben als den der höchsten Ordnungszahl, einen Übertrag auf eine 
zusätzliche Stelle bewirken. Im Gegensatz dazu regeln Additionssysteme wie das rö- 
mische Zahlensystem dieses Problem, ohne die Stellen genau zu beachten. Dort hat 
jedes Zeichen einen absoluten Wert. Tabelle 3.3 zeigt einige gängige Zahlensysteme 
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mit verschiedener Basis. Jede natürliche Zahl größer 1 kann Basis eines Zahlensys- 
tems sein.^ 



Tabelle 3.3. Die Alphabete gängiger Zahlensysteme 

Name Wertebereich Zahlensystem 
aß 2 = {0,1) Dualsystem 

aj3g ={0,1,2, ..7} Oktalsystem 

aß\o ={0,1,2, ..9} Dezimalsystem 

aßi(i = {0,1,2, .. 9, A, .. F) Hexadezimalsystem 



Warum haben beim Hexadezimalsystem plötzlich Buchstaben die Bedeutung von 
Zahlen? Es gibt keine anderen Gründe als historische. Man hatte keine Zeichen für 
die Wertigkeiten lOig bis 15i6- Bei Dezimalzahlen braucht man dafür zwei Stellen, 
genau das aber durfte für die Zwecke der Computertechnik nicht sein. Man hätte auch 
neue Zeichen definieren können, aber das gaben die von Computern verarbeitbaren 
Alphabete der 60er Jahre nicht her. 

Doch wie lässt sich die oben gegebene verbale Definition präziser ausdrücken? 
Jedes Stellenwertsystem lässt sich mit der folgenden Formel beschreiben bzw. der 
dezimale Wert W einer Zahl errechnen: 



N-l 

Wio = S (3.2) 

1=0 

mit: W = Zahlenwert, 5 = Stellenwert, N = Stellenzahl, B = Basis 

Die folgenden Beispiele zeigen die Benutzung von Formel 3.2: 

1994io= 1*10^ + 9*102 + 9*10^+4*10'’= 1000 + 900 + 90 + 4 

321g = 3*82 + 2 *8’ + 1*80 = 192+16+1 =209io 

1Di 6 = 1*16' + 13*160= 16+13 = 29io 

IIIIIOOIOIO 2 = 1 * 2 “ + 1 * 2 '’ + 1*2* + 1*22 + ... + 0*2°= 

Die Umrechnung einer Dezimalzahl in die Zahl eines anderen Systems erfolgt durch 
die zu Formel 3.2 Inverse Operation Division. Der Rechengang lässt sich nicht mit 
einem einfachen Operator beschreiben wie etwa 21, sondern in Form eines Algorith- 
mus. Er lautet: 

Teile die Dezimalzahl fortwährend durch die gewünschte Basis und notiere 
die Divisionsreste, bis der Quotient gleich 0 ist. Die Reste - von hinten nach 
vorne notiert - ergeben die gewünschte Zahl. 

Tabelle 3.4 zeigt dies an einem Beispiel. Es gilt also: 1994io = 7 CAiö oder auch 
(zum Üben): 

^ So benutzten 2000 v. Chr. die Bewohner Babylons das Sexagesimalsystem (60er-System), 
auf dem noch heute unsere Messung der Zeit und der Winkel beruht. 
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52648 = 2740io=A54i6. 



Tabelle 3.4. Umrechnung einer Dezimalzahl in eine Zahl zur Basis 16 

Division Quotient Restm Zifferig 

1994 : 16 = 124 lÖ Ä 

124: 16 = 7 12 C 

7:16 = 0 7 7 



Wir brauchen dies auch nicht bis in die Tiefen der Rechenwerke der Computer zu 
verfolgen. Zum Verständnis reicht ein Blick auf die Codes ASCII, EBCDI und UNI- 
CODE in Tabelle 3.5 (vgl. Stahlknecht & Hasenkamp, 2005, Abb. 2.2). 



Tabelle 3.5. Beispiele der Codiemng von Zahlen und Buchstaben 



Zeichen 


(lower) ASCII 
OrdnZ Dual 


EBCDI 

OrdnZ Dual 


(einfacher) UNICODE 
OrdnZ Dual 


0 


48 


0011 0000 


FO 


1111 0000 


0030 


0000 0000 001 1 0000 


1 


49 


0011 0001 


Fl 


1111 0001 


0031 


0000 0000 0011 0001 


2 


50 


0011 0010 


F2 


1111 0010 


0032 


0000 0000 0011 0010 


@ 


64 


0100 0000 


_ 


_ 


0040 


0000 0000 0100 0000 


A 


65 


0100 0001 


CI 


1100 0001 


0041 


0000 0000 0100 0001 


B 


66 


0100 0010 


C2 


1100 0010 


0042 


0000 0000 0100 0010 


C 


67 


0100 0011 


C3 


1100 0011 


0043 


0000 0000 0100 0011 


ß 


_ 


_ 


FF 


1111 1111 


OODF 


0000 0000 1101 1111 


ü 


127 


1111 1111 


- 


- 


007F 


0000 0000 1111 1111 


> 


- 


- 


- 


- 


FEB6 


1111 1110 1011 0110 



Zum Beispiel sieht man im ASCII-Code, dass das Zeichen ’O’ die Ordnungszahl 
48 hat und die anderen Zahl-Zeichen folgen. Also könnte man gängige Rechenopera- 
tionen schon auf der Ebene des Codes durchführen, indem man von jeder Ordnungs- 
zahl die Konstante 48 abzieht. Analog würde man beim Hexadezimalsystem für die 
Werte 10 bis 15 (= ’A’ bis ’E’) eine entsprechende Konstante 64 (= das Zeichen vor 
’A’) abziehen. Reale Rechner würden zwar viel zu langsam rechnen, wenn sie dies 
auf der Code-Ebene täten, hier geht es jedoch nur darum zu erkennen, dass es prinzi- 
piell möglich ist, statt mit Zahl-Zeichen auch mit anderen Zeichen zu rechnen. Von 
dieser Eigenschaft der Codes machen z.B. Suchmaschinen wie etwa google bei der 
Analyse von Texten intensiven Gebrauch. 

Wir können an Tabelle 3.5 noch mehr ablesen. Die Ordnungszahlen sind im 
ASCII-Code dezimal angegeben und benötigen drei Stellen, während sie im EBCDI- 
Code hexadezimal notiert sind und deshalb nur zwei Stellen brauchen. Die jeweili- 
gen dualen Entsprechungen nehmen sogar 8 Stellen in Anspruch, beim einfachen 
UNICODE 16. 
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Wir haben in Tabelle 3.5 ein Alphabet (Spalte 1) in mehrere andere übersetzt. 
Diesen Vorgang nennt man Codierung. Die Codierung aller denkbaren Zeichen für 
Zwecke der Verarbeitung in Computern erfolgt mit positiven ganzen Zahlen mit 0 
als kleinstem Element. Man kann also die Codierung von Zeichen eines beliebigen 
Alphabets und dessen Verarbeitung durch einen Computer nur verstehen, wenn man 
das duale Zahlensystem kennt und nicht nur von dualen Zuständen der einzelnen 
dualen Stellen erfährt. Wie wir auch aus Tabelle 3.5 ablesen können, werden die 
üblichen Zeichen etwa des ASCITCodes in 8 Stellen als duale Zahl abgebildet. Mit 
8 dualen Stellen kann man 256 = 2^ verschiedene Zustände abbilden, also genau den 
Zeichenvorrat erweiterter ASCII-Code. 

Der Zusammenhang von Stellenzahl und der Anzahl möglicher Zustände gilt 
allerdings für alle Codes und nicht nur für Zahlensysteme. Wenn man wissen möchte, 
wie viele Zustände Z ein Alphabet der Kardinalität B (= Basis) in einer Zeichenkette 
mit N Stellen ermöglicht, erhält man die Antwort mittels folgender Formel: 

Z = B^ (3.3) 



Tabelle 3.6. Codierung von Zahlen in verschiedenen Zahlensystemen 



dezimal 


dual 


oktal 


hexa- 

dezimal 


0 


0 


0 


0 


1 


0 0001 


1 


1 


2 


0 0010 


2 


2 


7 


0 0111 


7 


7 


8 


0 1000 


10 


8 


9 


0 1001 


11 


9 


10 


01010 


12 


A 


11 


0 1011 


13 


B 


15 


01111 


17 


F 


31 


1 1111 


37 


IF 



Wegen der vielfachen Anwendung hat eine duale Stelle einen Namen, Bit, und 
die häufig benutzte Einheit von 8 Bit den Namen Byte. Wir können jetzt auch begrün- 
den, warum das Hexadezimalsystem im Computerbereich so beliebt ist. Es ist nicht 
nur kompakter als das Dezimalsystem, sondern es nutzt auch den dualen Code besser 
aus. Dies kann man sich aus Formel 3.3 berechnen, die uns für das Oktalsystem mit 
genau 8 notwendigen Zuständen (2^ = 8) drei Stellen als notwendig ausweist und für 
das Hexadezimalsystem mit 16 Zuständen genau vier (2^ = 16). Das Dezimalsystem 
nutzt die vier notwendigen Stellen nicht vollständig aus. Dies kann man aus Tabelle 
3.6 für das oktale, dezimale und hexadezimale System ablesen (fett gedruckte Zif- 
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fern). Formel 3.3 spielt in vielen Bereichen der Informationsmodellierung und der 
Computertechnik eine praktische Rolle. 

So wird etwa die Fehlermeldung der Windows-Betriebssysteme Schwerer Ausnah- 
mefehler bei: <Hauptspeicheradresse> als Hexadezimalzahl gezeigt, weil die wirk- 
liche, duale Adresse völlig unüberschaubar wäre. Man bekommt als Benutzer zwar 
etwas ebenso Unverständliches wie die Dualzahl es wäre, die Nachricht ist aber im- 
merhin lesbar. Eine Information ist sie nur für wenige Spezialisten, die die Semantik 
der Zahl verstehen. 

Doch auch wirtschaftlich gewichtige Entwurfsentscheidungen hängen von diesem 
Zusammenhang ab, etwa Flerstellkosten für Flardware, sog. Schlüssel in der betrieb- 
lichen Praxis oder die Anzahl der über das Internet weltweit erreichbaren Adressen 
(sog. IP-Adressen), die nach dem heute (2005) noch gebräuchlichen Standard in we- 
nigen Jahren erschöpft sein wird. Wir werden diesen Aspekt in Kapitel 6, Seite 94 
am Beispiel sog. Schlüssel aufgreifen. 

Zum Abschluss dieses Abschnitts sind noch einige Anmerkungen zu dualen Co- 
des erforderlich. Obwohl die Stellenzahl bei ihnen am größten ist, arbeiten alle heute 
verbreiteten Computer intern dual, weil die Schaltungen in der Hardware damit am 
einfachsten werden. Dies gilt auch für die Übertragung von Daten in Netzen, mit 
oder ohne Kabel. Zur Datenübertragung genügt es hier zu wissen, dass die Übertra- 
gungsgeschwindigkeit der sog. Kanäle (Kabel, Radiowellen, Licht) so schnell ist, 
dass die Länge codierter Zeichen nicht ins Gewicht fällt und dass die Übertragungs- 
einheiten auch nur Computer sind. Es wird also die Anzahl der Zeichen durch die 
Geschwindigkeit der Übertragung kompensiert. 

Zusammenfassung Abschnitt 3.3 

o Wenn die Reihenfolge der Zeichen eines Codes genutzt werden soll, 
muss der Code als Alphabet definiert sein. Dann kann der Computer 
auch mit Nicht-Ziffern rechnen. 

o Ein Zahlensystem ist aus Sicht der Informationsdarstellung ein Alpha- 
bet, auf dem arithmetische Operationen definiert sind, 
o Die Kardinalität eines Codes bestimmt die Stellenzahl, die für eine In- 
formation benötigt wird. 

o Das Hexadezimalsystem nutzt den dualen Code besser aus als das Dezi- 
malsystem. 

Wir verfügen jetzt über alle Bausteine, um Daten und deren Klassifizierungen klären 
und verstehen zu können. 



3.4 Datentypen 

Der Begriff Daten war lange beschränkt auf maschinell verarbeitbare, speicherbare 
Zeichen, wobei damit nur digitale (= dual oder mit anderen Zahlensystemen codierte) 
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Zeichen gemeint waren. Heute muss man auch visuelle und akustische Codes (Bilder 
und Töne) hinzu zählen. Sie sind allerdings in der betrieblichen Realität von unter- 
geordneter Bedeutung, während sie den privaten Bereich längst dominieren. Unsere 
Grundlage sind also wegen des betriebswirtschaftlichen Kontextes immer noch zei- 
chenorientierte Daten und nicht bitorientierte. 

Innerhalb der zeichenorientierten Daten gibt es eine weitere wichtige Untertei- 
lung in unstrukturierte und strukturierte Daten. Am einfachsten kann man sich das 
an Hand zweier Komponenten von Office-Systemen auf Computern verdeutlichen. 
Für die unstrukturierten Daten (Texte) braucht man ein Textsystem, für die struk- 
turierten (Zahlen und deren Bezeichnungen) eine Tabellenverarbeitung, weil beide 
Arten von Daten mit verschiedenen Operationen zu bearbeiten sind. 

Wir besprechen zunächst elementare, dann zusammengesetzte Datentypen, da- 
nach die Namengebung von Daten und als letztes die Verknüpfung zusammenge- 
setzter Datentypen zu größeren Strukturen. 

3.4.1 Elementare Datentypen 

Tabelle 3.7 zeigt als Beipiel Artikeldaten eines Unternehmens, das kleinteilige Texti- 
lien verkauft. Wir erkennen in den Spalten der Tabelle verschiedene Typen von Daten 
(Dimension, Produktgruppe usw.). Sie abstrahieren von den konkreten Wer- 
ten, hier einem Produkt aus den Produktgruppen Feinstrümpfe (FS), Schlipse (SC) 
und T-Shirts (TS). 



Tabelle 3.7. Daten von textilen Produkten in der Struktur einer Tabelle 



ArtikelNr 


Bezeichnung 


Dimension 


PreisGrp 


Marke 


ProdGrp 


lieferbar? 


76248 


nur die sitzt 


St 


3 


ND 


FS 


ja 


90723 


Bellinda Stretch 


Bü 


5 


BE 


FS 


Ja 


10101 


Alpi superchic 


St 


9 


- 


SC 


nein 


10102 


T-Shirt Baumwolle einf. 


St 


10 


- 


TS 


Ja 



Wir wollen uns zunächst mit elementaren Datentypen als Grundlage jeder be- 
trieblichen Datenbasis befassen, das sind die Spalten von Tabellen. Zur Beschreibung 
benötigen wir eine formale Sprache. Da Programmiersprachen solche Sprachen sind, 
benutzen wir die Grundtypen der Sprache Java, nicht aber deren technisch bedingte 
Untertypen für verschiedene Genauigkeiten von Zahlen. 

Die einfachsten Datentypen kennen wir aus der Mathematik. Dies sind die gan- 
zen Zahlen Z und die gebrochenen (rationalen) Zahlen Q. Sie haben sehr verschiede- 
ne mathematische Eigenschaften, denn die ganzen Zahlen sind abzählbar, während 
die gebrochenen ein Kontinuum bilden, d.h. theoretisch beliebig viele Nachkom- 
mastellen haben können. Z und Q müssen deshalb auch in Computern verschieden 
abgebildet werden. Die reellen Zahlen M können wir in der endlichen Genauigkeit 
von Computern überhaupt nicht abbilden. 

Es ist selbstverständlich, dass wir Zahlen und die übrigen Zeichen voneinander 
trennen müssen, da mit ihnen sehr verschiedene Operationen durchzuführen sind. 
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Also muss es neben den Zahlen einen Typ Zeichen geben, das sind unsere schon 
erwähnten Alphabete. Sie umfassen auch die Zahl-Zeichen, also Ziffern. Weiterhin 
gibt es den für logische Operationen wichtigen Typ boolean, der nur die Werte wahr 
(true) oder falsch (false) annehmen kann. Er fehlt in vielen Programmiersprachen, 
obwohl er zur Vereinfachung von Programmen wichtig ist. Diese vier Typen bilden 
die Basistypen. Tabelle 3.8 zeigt die im weiteren Verlauf zu Grunde gelegten Basis- 
typen im oberen Teil, auf denen alle höher wertigen aufbauen. Im unteren Teil wer- 
den nicht wirkliche Basistypen gezeigt, sondern Typen, die aus pragmatischen Grün- 
den zu ihnen gezählt werden. Die Zeichenkette als Folge von Character-Elementen 
wird aus Handhabungsgründen immer zu den Basistypen gezählt, obwohl sie nicht 
wirklich elementar ist. In manchen Programmiersprachen wird auch noch der aus 
Tag, Monat und Jahr zusammengesetzte Typ Datum als Basistyp angeboten, 
ebenso die Zeit. 



Tabelle 3.8. Basistypen strukturierter Daten und deren pragmatische Erweiterungen 



Datentyp 


Name 


Operationen 


Ganze Zahlen 


integer 


rechnen, prüfen 


Gebrochene Zahlen float 


rechnen 


Zeichen 


character verketten, suchen, verschieben 


Wahrheitswerte 


boolean 


vergleichen 


Zeichenketten 


String 


verketten, suchen, austauschen 


Kalenderdaten 


date 


umformen, rechnen, Zulässigkeit 






prüfen 


Zeiten 


time 


wie bei date 



Tabelle 3.9 enthält ergänzend zwei benutzerdefinierte Datentypen, auch problem- 
spezifische Datentypen genannt. Sie schränken die Wertebereiche der aufzählbaren 
Basistypen (f loat ist nicht aufzählbar) so ein, wie der Benutzer es benötigt. So 
kann er die Zahlen von 1 bis 10 für irgendeinen Zweck eingrenzen ( 1 . . 10 ) , oder 
die Zeichen auf (’a’..’z’), also die kleinen Buchstaben. Diese stark eingegrenzten Ty- 
pen sind für betriebliche Daten besonders wichtig und auch sehr verbreitet, da ein 
großes wirtschaftliches Interesse daran besteht, Daten so exakt wie möglich zu defi- 
nieren. Dies hilft, durch Datenfehler verursachte Störungen in betrieblichen Prozes- 
sen zu vermeiden. Eine besonders wichtige Rolle spielt hierbei der Aufzählungstyp 
enum {Enumeration), der uns in Kapitel 5 als Kategorie wieder begegnen wird. 



Tabelle 3.9. Benutzerdefinierte elementare Datentypen 

Bezeichnung Name Basistyp Syntax Anmerkung 
Unterbereichstyp integer min..max Bedeutet: von..bis 

character min..max Basis muss ein Alphabet sein 
Aufzählungstyp enum string IVi ,VV 2 , ..,W« W) sind beliebige Strings 
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Die Basistypen und die benutzerdefinierten Datentypen bilden zusammen die ele- 
mentaren Datentypen. Daten in betrieblichen Datenbeständen werden nur auf der 
Ebene elementarer Typen als konkret zu verarbeitende Werte gespeichert. 

3.4.2 Zusammengesetzte Datentypen 

Die gesamte Tabelle 3.7 (Artikel) ist ebenfalls ein Datentyp, genannt zusammenge- 
setzter Datentyp . Durch ihn schreibt das Unternehmen fest, welche Eigenschaften es 
seinen Produkten zu Zwecken der maschinellen Verarbeitung zuspricht. Die Spalten 
der Datentahellen heißen Attribute oder auch Merkmale, die Zeilen sind dann die 
konkreten Exemplare, die aus Werten der Attribute bestehen. Die einzelnen Attribu- 
te unseres Beispiels Artikel sind in Tabelle 3.10 mit ihren elementaren Datenty- 
pen erläutert. Eine sehr ähnliche Attrihuttabelle mit genauer Spezifikation der Typen 
kann in (Chen, 1976, 21) nachgelesen werden. 



Tabelle 3.10. Der zusammengesetzte Datentyp Artikel mit Attributtypen 

Artikel 

AttributName AttributTyp Mögliche Werte Erläuterung 



ArtikelNr 


integer 


1000..9999 


historisch entstandene Nummern 


Bezeichnung 


String 


’A’..’Z’, ’a’..’z’, 


, nur diese Zeichen erlaubt 


Dimension 


enum 


Bü, St, m, g 


Bündel, Stück, Meter, Gramm 


PreisGrp 


integer 


1..10 


bis zu zehn Preisgruppen 


ProdGrp 


enum 


FS, SC, TS 


Feinstrümpfe, Schlipse, T-Shirts 


Marke 


enum 


ND, BE, - 


nur die, Bellinda, = no name 


lieferbar? 


boolean 


ja, nein 





So wurde etwa - dies ist ein authentischer Fall - durch die restriktive Definition der 
Artikelbezeichnungen (s. Tabelle 3.10) für die Zukunft verhindert, dass ein sich be- 
sonders pfiffig vorkommender Dynamiken als Bezeichnung ’nur die 5 Stück’ vergab. 

Dies hatte zur Folge, dass alle Dispositionsrechnungen falsch wurden, in denen die- 
ser Artikel vorkam. 

Wir werden in Kapitel 5 sehen, wie man das über Stücklisten richtig modelliert. 
Für betriehliche Zwecke werden bei vielen elementaren Daten die Basistypen ein- 
geschränkt, im Beispiel Artikel sind das alle außer dem Attribut lieferbar?. 
Dabei wird mit syntaktischen Mitteln zusätzliche Semantik hergestellt, die maschi- 
nell überprüfbar ist. Man nennt solche Festlegungen der zulässigen Werte von Daten 
Integritätsbedingungen. Es gelten also nur die Werte im Sinne des Unternehmens als 
„integer“ also als richtig,^ die dem Wertebereich der selbst definierten Datentypen 



® Die Wortwahl erfolgt nicht gedankenlos. Sie zeigt, wie auf engstem Raum eines Textes die 
Semantik eines Wortes mit dem Kontext wechselt, denn wir hatten ja gerade integer als 
ganze Zahl eingeführt. 
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entsprechen. Alle anderen Werte des Basistyps können nicht nur keine betriebliche 
Information bilden, sie gelten als falsch. 

Die Definition solcher Datenstrukturen ist als Abstraktionsarbeit prinzipiell 
nicht automatisierbar, sondern geistige Entwurfsarbeit, die Entscheidungen erfordert. 
An die Klarheit der Datendefinitionen ist gebunden, ob die verarbeitenden Program- 
me einfach oder unnötig kompliziert werden und ob die Information innerhalb der 
Organisation einheitlich verstanden werden kann. Zur Debnition gehören ganz be- 
sonders auch aussagefähige Namen . 

3.4.3 Datennamen 

Zu Beginn des Kapitels war schon angedeutet worden, dass die Tradition der Al- 
gebra, Variablen nur mit Buchstaben, etwa m, p oder w zu benennen, für unseren 
Kontext schlecht ist. Da sollte es schon - ähnlich dem Beispiel Artikel - Menge, 
Preis und I¥ert heißen. 

Die Namen der Attribute der Datentypen sollten möglichst aussagefähig verge- 
ben werden, allerdings mit pragmatischen Abkürzungen. Es ist zweckmäßig, den Da- 
tentyp als Kürzel anzuhängen. Hierfür verwendet man Standard-Abkürzungen, wie 
sie Tabelle 3.11 beispielhaft benennt. Damit ist schon angedeutet, dass Sprache bei 
der Modellierung von Daten eine wesentliche Rolle spielt. Die Namen von Tabellen 
und Attributen sind Begriffe für semantische Sachverhalte. Schon bei Schmalenbach 
(1963, 28) kann man nachlesen, „daß Namen einer Sache zum Schicksal werden 
können.“ 



Tabelle 3.11. Standard-Abkürzungen in Attribut-Namen 



kurz 


lang 


Datentyp 


Dat 


Datum 


date 


Kls 


Klasse 


enum 


Grp 


Gruppe 


enum 


Nr 


Nummer 


integer 


Knz 


Kennzeichen 


enum 


Anz 


Anzahl 


integer 


Mg 


Menge 


f loat 



Durch einheitliche Namen und Abkürzungen, wie sie Tabelle 3.11 zeigt, lassen 
sich Begriffe unternehmensweit standardisieren. Hierdurch gelang es in einem mit- 
telgroßen Unternehmen, die Anzahl der Attribute der Datenbasis von 19.000 auf 800 
zu reduzieren (s. Spitta, 1996). 

3.4.4 Verknüpfte Datenstrukturen 

Mit Artikel wurde ein Beispiel gewählt, das unabhängig von anderen Datentypen 
ist. Dies ist bei den meisten Tabellen betrieblicher Daten genau nicht der Eall. Sie 
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sind vielfältig miteinander verknüpft und damit voneinander abhängig. Ein wichtiges 
Standardbeispiel demonstriert dies in Abb. 3.1. Wir sehen vier zusammengesetzte 
Datentypen als Grafik und als Tabellenkopf. Kursiv gedruckte Attribute des Typs Nr 
dienen als Referenz bzw. Zeiger auf andere Tabellen. Die Datentypen Artikel und 
Kunde sind unabhängig, denn sie enthalten keine Attribute, die auf andere Tabellen 
zeigen. Auftrag und Auftragsposition sind von Artikel und Kunde und 
voneinander abhängig. 




Als Datentypen: 

Kunde (KundenNr, Nante, Adresse) 



Auftrag (AuftragsNr, KundenNr, LieferDat) 

t 

AuftragsPos (AuftragsNr, ArtikelNr, Menge) 



Artikel (ArtikelNr, Bezeichnung, Dimension, Preis) 



Abb. 3.1. Verknüpfung von Datentypen über Attribute 



Die Verknüpfung kann auch über die Tabellen selbst mit Beispielwerten gezeigt 
werden. 



Tabelle 3.12. Vier verknüpfte Datentabellen 



Kunde 

(KundenNr, Name) 


Auftrag 

(AuftragsNr, KundenNr, LieferDat) 


17265 Edeka 

17270 Tengelmann 


1221 17265 17.05.2005 

1222 17270 17.05.2005 


Artikel 

(ArtikelNr, Bezeichnung) 


AuftragsPos 

(AuftragsNr, ArtikelNr, Menge) 


76248 nur die sitzt 

10102 T-Shirt Baumwolle einf. 


1221 76248 750.000 

1221 10102 6.000 

1222 76248 620.000 



Man sieht in Tabelle 3.12, wie die abhängigen Datentypen auf die unabhängigen 
zeigen. Die KundenNr im Auftrag zeigt auf den entsprechenden Kunden, also ge- 
nau die Tabellenzeile, die einen konkreten Kunden repräsentiert. Die ArtikelNr 
in der Auftragsposition zeigt auf den beauftragten Artikel. Jede Zeile der Tabelle 
AuftragsPos zeigt auf den Auftrag, zu dem sie gehört. Weiterhin zeigen die kur- 
siv gedruckten Nummern (Typ Nr), dass die Tabelle AuftragsPos keine eigen- 
ständige Nummer hat, sondern von Auf trag und Artikel über Zeiger abhängig 
ist. 
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Wir haben hier Begriffe wie Schlüssel oder Primärschlüssel vermieden, die eini- 
ge Leser vielleicht jetzt erwartet hätten. Sie sind zunächst für das weitere Verständnis 
nicht erforderlich. Wir werden sie erst in Kapitel 6 im Zusammenhang mit der Me- 
thodik der Datenmodellierung kennen lernen und dabei sehen, dass durch Verknüp- 
fung vieler solcher zusammengesetzter Datentypen eine betriebliche Datenbasis als 
komplexes Gefüge von Tabellen entsteht. 

Andere Strukturtypen (Bäume, Netze) haben für die Struktur betrieblicher Daten 
nur noch historische Bedeutung und werden hier nicht behandelt. 

Um die Rede von den Datenstrukturen sprachlich zu vereinfachen und an neue 
Entwicklungen anzuknüpfen, sprechen wir im Folgenden von Objekttypen und nicht 
mehr von zusammengesetzten Datentypen. Ein sehr gebräuchliches Synonym für Ob- 
jekttyp ist Entitätstyp. Eine Entität wie auch ein Objekt ist ein identifizierbarer realer 
oder gedachter Gegenstand unserer Umwelt bzw. ein einzelnes Element eines Sys- 
tems. 

Zusammenfassung Abschnitt 3.4 

o Es gibt eine eng umgrenzte Anzahl elementarer Datentypen, in denen 
wir alle Attribute strukturierter Daten ausdrücken müssen, 
o Eine besondere Bedeutung haben dabei die benutzerdefinierten Daten- 
typen, mit denen Unterbereiche und Aufzählungen entsprechend dem 
betrieblichen Diskursbereich festgelegt werden, 
o Auf der engen Einschränkung von Datentypen beruht die Definition von 
Integritätsbedingungen, auch Geschäftsregeln genannt, 
o Daten müssen unternehmensintern verständliche und einheitliche Na- 
men erhalten. 

o Die Unternehmensdaten setzen sich aus miteinander vernetzten Tabellen 
zusammen. 



3.5 Wiederholung 

• Betrieblich bedeutend sind überwiegend zeichenorientierte Daten, von ihnen 
wiederum die strukturierten. 

• Unstrukturierte Daten sind Texte. 

• Die strukturierten Daten werden als elementare Datentypen so eng eingegrenzt 
wie möglich. Die Eingrenzung erfolgt mit Unterbereichs- und Aufzählungstypen. 
Vor allem letztere sind von großer praktischer Bedeutung. 

• Nur elementare Daten können Werte repräsentieren. 

• Eine Menge elementarer Datentypen heißt zusammengesetzter Datentyp (= Ob- 
jekttyp). Wir betrachten ausschließlich den Strukturtyp Tabelle, der die größte 
Bedeutung für betriebliche Daten hat. 

• Mehrere Tabellen können über bestimmte Attribute miteinander verknüpft wer- 
den. Diese dienen als Zeiger. 




40 



3 Daten 



• Eine konsistente Namengebung ist für die Komplexitätsreduktion der betriebli- 
chen Datenbasis und die Verständigung innerhalb des Unternehmens sehr wich- 
tig- 

Wir verfügen jetzt über eine Basis, auf der wir qualifiziert über Kommunikation, 
Information und Wissen sprechen können. 
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Kommunikation, Information und Wissen 



In diesem Kapitel soll geklärt werden, was Kommunikation zwischen Menschen 
und zwischen Automaten ist und wie man auf dem Nachrichtenbegriff aufbauend 
Information und danach Wissen erklären kann. Betriebliche Information in Routine- 
prozessen, gestützt auf Automaten, kann ohne eine konkrete Vorstellung von Daten 
nicht verstanden werden. 



4.1 Nachrichten und Kommunikation 

Kommunikation ist der Austausch von Nachrichten zwischen Sendern und Emp- 
fängern, die mittelbar und unmittelbar Menschen oder Automaten sein können. Die 
Anforderungen an die Beschaffenheit der Nachricht hängen von der Art des Senders 
oder des Empfängers ab. 

4.1.1 Kommunikation zwischen menschlichen Akteuren 

Abb. 4.1 zeigt ein einfaches Kommunikationsmodell. Sind Sender und Empfänger 
menschliche Akteure, genügt auch ein nicht ganz deckungsgleicher Zeichenvorrat (s. 
Bild, Syntaxfehler sind tolerierbar) und eine gemeinsame semantische Basis, damit 
sie einander verstehen. 




Nachricht 





— ->■ = unidirektionaler, 

asynchroner Kanal 



Abb. 4.1. Kommunikation als Nachrichtenübermittlung (unidirektional) 
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Das Phänomen der Abb. 4. 1 kennen wir von Fax oder E-Mail. Beim Telefon wäre 
der Kanal bidirektional', damit wären auch die Rollen Sender und Empfänger nicht 
mehr klar zugewiesen. Das würde durch einen Pfeil mit zwei Spitzen (^) ausge- 
drückt. Streng genommen, spricht man erst von Kommunikation, wenn Nachrichten 
bidirektional ausgetauscht werden, die eine Erage-Antwort-Struktur haben. Wir wer- 
den jedoch sehen, dass auch unidirektionale Nachrichten zwischen menschlichen 
Akteuren auf der technischen Ebene bidirektional bearbeitet werden. 

Die Vielschichtigkeit menschlicher Kommunikation können wir hier nicht be- 
handeln. Spätestens seit den siebziger Jahren wissen wir, dass sie nie ausschließ- 
lich rationale Bestandteile hat, sondern dass immer eine Beziehungsebene mit hinein 
spielt (s. Watzlawick, Beavin & Jackson, 1974). Die zwischenmenschlichen Aspekte 
von Kommunikation haben mitunter erhebliche wirtschaftliche Wirkungen (s. hierzu 
Spitta, 1989, Kap. 9; Picot & Reichwald, 1991, Abschn.I). Dies ist aber ein Thema 
der Personalwirtschaft. Wir beschränken uns hier auf die informationswirtschaftli- 
che Sicht, bei der im Regelfall Automaten (vom Telefon bis zum Conmputer) an der 
Kommunikation beteiligt sind. 

4.1.2 Kommunikation zwischen Automaten 

Eine Kommunikation über Eax oder E-Mail benötigt Automaten, die die Datenüber- 
tragung bewerkstelligen. Diese können unscharfe Nachrichten, wie in Abb. 4. 1 ge- 
zeigt, auf einfache Weise nicht verstehen. Vielmehr benötigen sie exakt übereinstim- 
mende Zeichenvorräte und Datentypen. Die Übermittlung erfolgt mit Protokollen, 
bei denen die inhaltliche Nachricht in einem bis auf das Bit festgelegten Teil einge- 
schlossen ist, der aus einem Kopf (header) und einem Euß (trailer) besteht. Header 
und Trailer müssen exakt dem Standard entsprechen, sonst weist der empfangende 
Automat die Nachricht ab. Den Inhalt gibt der Automat ungeprüft an den mensch- 
lichen Empfänger weiter.* Die Automaten kommunizieren bei Protokollen immer 
bidirektional, auch wenn die Nachricht unidirektional ist. Der automatische Sender 
wartet dabei auf eine Quittung des empfangenden Automaten. 

Die Quittung kommt etwa beim Fax nicht, wenn das Empfangsgerät das gesendete 

Fax aus irgend einem Grund nicht vollständig drucken konnte. 



Header 



Nachricht 



Trailer 



Abb. 4.2. Aufbau von Protokollen 



Abb. 4.2 zeigt den prinzipiellen Aufbau von Protokollen. Ist die Nachricht ein un- 
strukturierter Text wie beim E-Mail-Protokoll, spricht man von Transportprotokol- 
len, besteht sie aus exakt strukturierten Datentypen, sprechen Hansen & Neumann 
(2005) von Anwenderprotokollen. Solche höheren Protokolle haben eine große wirt- 
schaftliche Bedeutung, da Firmen Daten vollautomatisch austauschen wollen. Dies 

* Von Spezialfällen wie SPAM-Filtern wollen wir hier absehen. 
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geschieht etwa mittels der Protokolle des Typs EDIFACT (Electronic Data Inter- 
change for Administration, Commerce and Transport, ein Standard der UNO), bei 
der Computer eines Lieferanten Sender und die des Kunden Empfänger von Rech- 
nungen, Bestellungen oder ähnlichen Datenstrukturen sind. Alles geschieht automa- 
tisch, ohne Postversand und menschlichen Eingriff. Solche Protokolle verlangen er- 
hebliche Sorgfalt bei der Festlegung von Zeichen, Worten und Inhalten. Der Emp- 
fänger muss jedes Zeichen und jedes Wort genau so verstehen wie der Sender. 

Die Unterscheidung in uni- und bidirektionale Nachrichten führt auf ein weite- 
res, konzeptionell wichtiges Begriffspaar. Eine Kommunikation synchron, also 
zeitgleich sein oder asynchron, also zeitversetzt. Ein Telefongespräch erfolgt syn- 
chron, eine E-Mail oder ein Papierbrief werden asynchron zugestellt. Der Dialog mit 
einem Computer erfolgt synchron. Die Benutzerschnittstelle des Personalcomputers 
ist auf direkte Interaktion mit dem Gerät ausgelegt. 

Viele wirtschaftlich bedeutsame Anwendungen von Computern entfalten ihre 
Möglichkeiten zur Effizienzerhöhung von Abläufen erst im asynchronen Betrieb, 
auch Batchverarbeitung genannt. Per Automat oder menschlichem Bediener wird 
ein eventuell länger dauernder Prozess angestoßen, der nicht auf Antworten eines 
menschlichen Kommunikationspartners angewiesen ist, sondern vollautomatisch al- 
le Arbeitsschritte erledigt und seine Ergebnisse in einem Speicher ablegt. Hier zwei 
Beispiele: 

o In einem Unternehmen mit vielen täglichen Verkaufspositionen an andere Unter- 
nehmen startet am Abend jedes Arbeitstages automatisch der Prozess Fakturie- 
rung, der mehrere Stunden Zeit beanspruchen kann. Nach dessen Ende werden 
die Ergebnisse im EDIEACT-Eormat an die Großkunden übermittelt und von de- 
ren Computern nach Prüfung auf formale Korrektheit zwischengespeichert. Jede 
korrekte Rechnung wird durch einen weiteren Prozess automatisch in die War- 
teschlange des Buchhaltungsprogramms des Kunden gestellt. Sie heißt offener 
Posten und wird zumindest bei betragsmäßig größeren Rechnungen von einem 
menschlichen Bearbeiter im Dialog geprüft, bevor die automatische Zahlung er- 
folgt. Diese geschieht mit dem nächsten Akteur, der Bank. 

o Wir könnten mit google im Dialog fast nichts finden, wenn die Eirma Google 
nicht täglich automatische Prozesse anstoßen würde, die das Internet durchsu- 
chen und bei Google entsprechende Indexbäume pflegen. Erst dies ermöglicht 
uns den gewohnten schnellen Zugriff mit hunderttausenden von Treffern in we- 
nigen Sekunden. 

Doch auch Dialoganwendungen können essenziell für Erfolg oder Misserfolg eines 
Unternehmens sein. Der Vorteil synchroner Anwendungen liegt im Bereich der Ein- 
gabe von Daten durch menschliche Akteure. Nur die Akteure wissen, welche Daten 
aus ihrer Sicht die richtigen sind. Der Computer wiederum „weiß“ - bei sinnvoll ent- 
worfenen Integritätsbedingungen - welche Daten er für richtig halten darf. Er muss 
also synchron, mittels verständlicher Fehlermeldungen, den Benutzer zur Eingabe 
der korrekten Daten veranlassen, der allein wissen kann, was semantisch richtig ist. 



So steht etwa bei einer Bestellung von Ware im Internet hinter der Meldung „Wa- 
re nicht lieferbar, wählen Sie einen der angebotenen AlternativartikeF das System 
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eines Anbieters, das in der Lage ist, synchron - also in einer schnellen sog. Antwort- 
zeit - den Lagerbestand zu prüfen. Kann das System einen Termin nennen, wann der 
gewünschte Artikel wieder lieferbar sein wird, hat es auch noch den Bestellbestand 
geprüft. Kann ein Anbieter dagegen erst nach drei Tagen per Brief reagieren, of- 
fenbart er durch diese asynchrone Antwort seine mangelnde Professionalität. Diese 
bestraft bekanntlich der Markt. 

Es hat zu Zeiten des Internet-Booms (um 2001) nicht Wenige gegeben, die solch eine 
Anwendung für etwas Neues hielten und „E-Business“ nannten. Die Anwendung ist 
aber weder betriebswirtschaftlich noch technisch neu. Es handelt sich um eine Auf- 
tragserfassung für Direktbesteller, bei der die Erfassungsmaske ins Internet verlegt 
wurde. Im Gegensatz dazu ist die Mehrzahl der Textseiten im Internet passiv. Sie 
bieten nur eine asynchrone Kommunikation, selbst wenn sie animiert sind. 

Zusammenfassung Abschnitt 4.1 

o Betriebliche Nachrichten werden häufig als Texte zwischen Sendern und 
Empfängern übermittelt. Dies erfolgt uni- oder bidirektional bzw. syn- 
chron oder asynchron. 

o Kommunikation erfolgt bidirektional. Sie erlaubt zwischen menschli- 
chen Akteuren Unschärfen in der Syntax der Nachrichten, 
o Protokolle sind standardisierte Datenstrukturen für die automatische 
Übertragung von Nachrichten. Sie tolerieren keine Unschärfen, 
o Asynchron übermittelte Nachrichten können nur von Automaten emp- 
fangen werden. Hierzu sind Protokolle erforderlich. 



4.2 Information 

Auf der Basis der Nachrichtenübermittlung können wir jetzt in erster Näherung nach 
Endres (2004) definieren: Information sind interpretierbare, d.h. mit Bedeutung ver- 
knüpfte, meist neue Nachrichten, die von einem Empfänger für das Verfolgen seiner 
Ziele als nützlich gewertet werden. 

4.2.1 Information für Einzelne 

Kern der ersten Präzisierung von Information, die von der Disziplin Wirtschaftsin- 
formatik mehrheitlich getragen wird (vgl. z.B. Ferstl & Sinz, 2001; Mertens et al., 
2005), ist die Subjektivität des Empfängers und das Kriterium Relevanz. Des Einen 
Information ist des Anderen „Schnee von gestern“, also nur Nachricht. „Ich gebe 
Dir eine Information “ wäre nach dieser Definition nicht möglich, weil darüber nur 
der Empfänger entscheiden kann. Die systemtheoretische Schule der Soziologie hat 
denselben Informationsbegriff: 

„Daten beobachten Unterschiede .., Informationen .. die von einem Beobachter für 
relevant gehaltenen Unterschiede.“ (Willke, 2004, 31) 
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Die Betriebswirtschaftslehre arbeitet seit Jahren (s. z.B. Weiber, 2002, 147ff.) mit 
der von Wittmann (1959) gegebenen Definition, dass Information „zweckorientiertes 
Wissen“ sei. Wir halten diese Definition nicht für nützlich, da sie einen unscharfen 
Begriff durch einen anderen erklärt, der noch unscharfer ist. Dahinter steht das In- 
formationsverständnis der Semiotik (Lehre von den Bedeutungen), das mit dem Auf- 
kommen der Informationstechnik in den 60er bis 80er Jahren adaptiert wurde. Die 
Semiotik postuliert eine Hierarchie Syntax Semantik Pragmatik mit Zeichen 
als unterster Ebene. Das Modell ist jedoch zu einfach, weil Syntax und Semantik 
über viele Ebenen zyklisch miteinander verflochten sind. 

Das lässt sich an zwei simplen Beispielen zeigen. Auto und Car haben eine 
verschiedene Syntax, jedoch dieselbe Semantik. Andererseit ist die Semantik von 
Homonymen wie Schloss, also verschiedenen Dingen mit derselben Syntax, je nach 
Kontext verschieden. Die einfache Hierarchie trägt also nicht. Das Modell versagt 
endgültig, wenn Daten eine Semantik zugesprochen werden soll, die sie gemäß Ab- 
schnitt 3.4 ohne Zweifel haben. Die Typenlehre aus Kapitel 3 zielt sogar genau darauf 
ab, bestimmte Aspekte von Semantik syntaktisch festzulegen mit dem Ziel, auf diese 
Weise maschinelle Verarbeitungen zu ermöglichen. Neue Entwicklungen etwa von 
XML (Extensible Markup Language) erweitern dieses Konzept auf unstrukturierte 
Daten. Wir gehen in Kapitel 9 darauf ein. 

Eine interdisziplinäre, sehr lesenswerte Definition und Diskussion des Begriffs 
Information findet sich in einem sonst nicht für alle Einträge empfehlenswerten offe- 
nen Lexikon im Internet (Wikipedia, 2005 Portal: Information & Kommunikation 
^ Information). 

Am Beispiel von Tabelle 3.10 (Attributtypen von Artikel) können wir auch 
noch einen letzten Aspekt des Informationsbegriffs beleuchten, bevor wir eine end- 
gültige Definition geben. Schon das Verstehen einer Nachricht ist gebunden an einen 
Kontext. Dies gilt nicht nur für das vielleicht extreme Beispiel des aus dem Engli- 
schen übernommenen integer als Datentyp und das Eremdwort integer, sondern 
für viele andere Situationen, in denen Nachrichten verstanden werden sollen. Wir 
können nach Endres Information als ein Tripel 

1={A*,S,K) (4.1) 

definieren, „wobei A* = wi,W2, --Wn eine Menge von Wörtern w; über einem Alpha- 
bet A, S eine Menge von Symbolen und K einen Kontext bedeutet“ (Endres, 2004, 
90). Information wäre dann eine Nachricht über einem definierten Alphabet und an- 
deren Symbolen, die für den Empfänger neu und relevant ist und deren Kontext er 
kennt. 

Dies bedingt nicht, dass eine Information immer in Eorm von Daten übermittelt 
wird. In betrieblichen Kontexten von Routinevorgängen ist dies jedoch häufig der 
Eall. Es ist sogar zwingend, wenn Prozesse automatisiert wurden, bei denen Infor- 
mationen, nicht nur Daten, routinemäßig übermittelt werden. Dies spielt bei Normen 
zur automatischen Informationsübertragung wie z.B. EDIPACT eine große Rolle. 
Neben dem Transport der Datenstrukturen und der expliziten Benennung des Kon- 
textes (z.B. INVOIC = Rechnung) wird technisch sicher gestellt, dass die übertrage- 
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ne Nachricht wirklich eine Information ist, indem sie nur genau einmal übertragen 
werden kann. Sie ist also immer neu und als notwendiger Bestandteil eines Routi- 
neprozesses sicher auch relevant. Zur Einmaligkeit automatisch übermittelter Infor- 
mation zwei Beispiele. Erstens darf jede Buchung immer nur genau einmal erfolgen 
und zweitens sind betriebliche Vorgänge wie Zahlungen, Lieferungen und ähnliche 
Transaktionen nur einmalig hilfreich, bezogen auf dasselbe Exemplar. 

Wir werden später sehen, dass entsprechend modellierte Daten die Sicherstellung 
der Einmaligkeit durch sog. Primärschlüssel unterstützen. 

4.2.2 Information für Kollektive 

Es wäre höchst ineffizient, nur einzelne Akteure miteinander kommunizieren zu las- 
sen. Um Kollektive zu informieren, benötigt man im Allgemeinen Datenspeicher 
als Puffer für Nachrichten. Wie Tontafeln und Bücher zeigen, ist das nichts Neu- 
es. Seit der Entwicklung von Computern mit entsprechenden Speichermedien haben 
sich jedoch die Möglichkeiten der automatischen Verarbeitung gespeicherter Daten 
dramatisch erweitert. 

In Abb. 4.3 führen wir dafür eine Erweiterung von Abb. 4.1 um zwei neue Kon- 
strukte ein: Einen Speicher als Sender und mehrere Empfänger. Dass das Senden 
durch einen Automaten (ein Computerprogramm) erfolgt, wollen wir hier vernach- 
lässigen. Wichtig ist aber, dass die Daten einer an mehrere Akteure verteilten Nach- 
richt nur genau einmal {redundanzfrei) gespeichert werden dürfen, damit sie konsis- 
tent sind. Wie man Daten strukturieren muss, um dies zu erreichen, wird in Kapitel 
6 behandelt. 



Enp länger 



Sender 




Abb. 4.3. Nachricht aus einem Speicher an viele Empfänger 



Damit die eigentlich individuelle Information entsprechend Abb. 4.3 auch kol- 
lektiv gleich verstanden werden kann, muss sie eine möglichst eindeutige Struktur 
haben. Dies ist nur mit strukturierten Daten (vgl. z.B. Tabelle 3.7, Artikel) mög- 
lich. Es kommt darauf an, dass alle Empfänger in einem wirtschaftlichen Umfeld 
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dieselbe Nachricht N gleich verstehen. Der Speicher sorgt dafür, dass die Nachricht 
nachvollziehbar und wiederholt abrufbar bleibt. Sie kann damit jederzeit zur Infor- 
mation für Kollektive von Akteuren werden. Genau das aber bezweckt man mit Da- 
ten in einem Unternehmen. Ein Nebeneffekt der strukturierten Daten ist, dass sie im 
Routinebetrieb eindeutige Informationen geben, um diesen Bereich des betrieblichen 
Geschehens möglichst frei von Störungen zu halten. Nicht gelingen wird dies mit un- 
strukturierten Daten, etwa einem Geschäftsbericht. Er wird verschiedenen Akteuren 
verschiedene Informationen liefern. 

Wir können also durch wohl überlegte Datentypen dafür sorgen, dass die betrieb- 
liche Datenbasis allen Mitgliedern der Organisation mit hoher Wahrscheinlichkeit 
dieselbe Information liefert. Hierzu muss allerdings nicht nur die Datenbasis formal 
und inhaltlich homogen sein, sondern die Organisation bestimmte Eigenschaften auf- 
weisen. Dies ist Gegenstand des nächsten Abschnitts. 

Zusammenfassung Abschnitt 4.2 

o Die Informationseigenschaft einer Nachricht erfordert einen gemeinsa- 
men Kontext und die Relevanz der Nachricht für den Empfänger. 

o Das Eeststellen der Informationseigenschaft ist nur subjektiv durch den 
Empfänger möglich. 

o Information kann mittels streng formalisierter Daten automatisch über- 
mittelt werden. Empfänger fallweiser Informationen sind direkt oder in- 
direkt menschliche Akteure. 

o Automaten können die Informationseigenschaft einer Nachricht sicher 
stellen (Neuigkeit durch Einmaligkeit). 

o Die Einmaligkeit von Nachrichten ist bei vielen betrieblichen Transak- 
tionen zwingend. 

o Speicher ermöglichen es uns, Nachrichten asynchron und beliebig oft zu 
versenden. 

o Durch strukturierte Daten erhöhen wir die Wahrscheinlichkeit, dass eine 
Nachricht von Kollektiven gleich verstanden wird, dass also eine einheit- 
liche Information der Akteure erreicht werden kann. 



4.3 Betriebliches Wissen 

Was der Alltagsbegriff Wissen in welchem Kontext bedeutet, ist vielschichtig und 
keinesfalls allgemeiner Konsens. Die Spanne reicht von der in Abschnitt 4.2 zitierten 
Informationsdefinition von Wittmann, der Wissen intuitiv verwendet, über Wissens- 
management in Unternehmen (Nonaka & Takeuchi, 1995) bis zu einer allmählich 
entstehenden Wissengesellschaft der Soziologie (Willke, 2001, Kap. 5). Eür die Zwe- 
cke der betrieblichen Informationswirtschaft wollen wir uns auf drei Eragestellungen 
beschränken: 

1 . Ist Wissen eine betriebliche Ressource, die man handhaben, also managen kann? 
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2. Was könnte organisationales Wissen eines Unternehmens sein? 

3. Was hat dies mit Daten und Information zu tun? 

4.3.1 Ist Wissen eine handhabbare Ressource? 

Zur Beantwortung von Frage 1 wollen wir bei einem intuitiven Verständnis von Wis- 
sen ansetzen, zunächst beim einzelnen Akteur. So lange eine Person es nicht äußert 
oder aufschreibt, ist ihr Wissen implizit. Es liegt nicht in Form von Daten vor, ist 
von der Person auch in vielen Fällen nicht explizit formulierbar (das sog. „Gefühl“). 
In unserem Kontext kann nur explizites Wissen betrachtet werden, das in Form von 
Daten vorliegt (z.B. analoges Band, digitaler Speicher). Trifft ein Manager eine Ent- 
scheidung, wird er dies auf der Basis von Daten und seines impliziten Wissens tun. 

Wird eine Entscheidung einem Optimierungsalgorithmus übertragen, wird aus- 
schließlich auf der Basis von Daten entschieden. Ob die in Eorm eines Computer- 
programms vorliegenden Handlungsanweisungen Daten oder Wissen sind, kann ver- 
schieden gesehen werden. Wir betrachten hier auch Programme als Daten, werden 
sie aber in diesem Buch nicht behandeln. Zur Begründung sollte genügen, dass Pro- 
gramme allzu oft unverständlich sind, so dass ein Verstehen des in ihnen steckenden 
Wissens unmöglich ist. Auf sie wäre also allenfalls die Kategorie implizites Wissen 
anwendbar. Als Daten betrachtet, sind Programme lediglich Texte, geschrieben in 
einer formalen Sprache. Auch ein mathematischer Beweis ist nur ein Text. In bei- 
den Fällen steckt allerdings hinter der Syntax eine komplexe Semantik. Als Nach- 
richt verwendet, hängt es vom impliziten Wissen des Empfängers ab, ob die Texte 
Informationen sein können oder nicht. Wissen, das sich auf Daten stützt, umfasst 
zwingend dme Handlungskompetenz (s. hierzu Talaulicar, 2004), diese in adäquater 
Weise zu nutzen. Die Handlungskompetenz umfasst implizites Wissen. Dies bedeu- 
tet, dass der Wissensbegriff eines Lexikons oder eines Ratewettbewerbs im Fernse- 
hen falsch ist (Willke, 2001, 12). Es handelt sich auch bei im Gehirn gespeicherten 
Gedächtnisinhalten um Daten, wenn auch in einer Repräsentation, die wir noch nicht 
vollständig verstehen. 

Handhabbar sind also Daten und in gewissem Umfang die Handlungskompetenz 
des Mitarbeiters. Man spricht also zu Recht von einer handhabbaren Ressource. 

4.3.2 Wissens- und Datenmanagement 

Jetzt ist der Blick auf Kollektive von Akteuren auszuweiten, etwa Organisations- 
einheiten oder ganze Unternehmen. Entsprechende Untersuchungen von Nonaka & 
Takeuchi (1995) und Willke (2001) weisen aus, dass es auch Wissen als betriebli- 
che Ressource gibt, die sogar für die Zukunftsfähigkeit von Unternehmen besonders 
wichtig werden kann. 

Nun könnte man als einfache Beispiele für betriebliches Wissen geheim zu hal- 
tende Rezepturen und Produktionsverfahren wie etwa die Rezepte für Nivea Creme 
oder Coca Cola benennen. Dies wären geheim zu haltende Daten, die besonders 
geschützt werden müssen. Doch dies ist zu vordergründig, denn organisationales 
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Wissen umfasst erheblich mehr als Daten. Es könnte eher mit einem Begriff wie 
Unternehmenskultur Umrissen werden, die innovativ oder defensiv sein kann. 

Obwohl Wissensmanagement sicher zum Thema Informationswirtschaft gehört, 
können wir es in diesem einführenden Buch nicht tiefer gehend behandeln. Wir be- 
schränken uns auf die Frage: Tragen Daten zum organisationalen Wissen bei und 
wenn ja, wie? 

Betriebliche Daten als Ressource benötigen ein Datenmanagement (s. Dippold, 
Meier, Ringgenberg, Schulder & Schwinn, 2005, Kap. 11), das von einer Institution 
durchgeführt wird, die sich inhaltlich um die in Datenbanken abgelegten Unterneh- 
mensdaten kümmert. Dies ist keine technische Funktion. Eine solche gibt es mit 
abnehmender Bedeutung noch in Form des Datenbankmanagements, das jedoch zu- 
nehmend automatisiert wird. Im Zusammenhang mit Wissen gibt es zwei Grundfra- 
gen des Datenmanagements, die Namengebung, hinter der eine unternehmensweite 
Sprachkultur steht, und die Redundanzfreiheit, hinter der die Eindeutigkeit gespei- 
cherter Fakten und Pläne steht. 

1. Namengebung. Datenstrukturen bezeichnen komplexe Objekte der realen oder 
gedachten Welt. Sie lassen sich auf atomare Objekte zurückführen, in Kap. 3 
als Merkmale bzw. Attribute bezeichnet. Alle Ebenen von Daten bedürfen eines 
Namens, um sie ansprechen zu können. Diese Namen sind wichtige Bausteine 
der Sprachkultur und damit auch von Denkstrukturen in einem Unternehmen 
(s. Ortner, Schienmann & Thoma, 1996). Sie transportieren nicht nur implizites 
Wissen, sie definieren bei zusammengesetzten Datentypen sogar Begriffe. Die 
Attribute, die wir einem Artikel zusprechen, definieren unsere Sicht, was wir 
unter einem Artikel verstehen wollen (s. Tabelle 3.7). 

2. Redundanzfreiheit. Es gibt nicht nur die Datenobjekte selbst, sondern auch Be- 
ziehungsgeflechte, die zusammengesetzte Datentypen untereinander bilden. In 
der Informatik heißen solche begrifflichen Strukturen Semantische Netze, in der 
Wirtschaftsinformatik ist eher der etwas speziellere Name Datenmodelle üblich. 
Eine integrierte Datenbasis, die von einem Unternehmen effizient genutzt und 
durchschaut werden soll, sollte keine redundanten Daten enthalten. Diese Ei- 
genschaft ist ihr zuzusprechen, wenn jedes Faktum nur genau einem Objekttyp 
zugeordnet ist und nicht mehreren Typen des Beziehungsgeflechtes. Nur eine 
redundanzfreie Datenbasis kann Teil einer expliziten Wissensbasis des Unter- 
nehmens sein, denn Redundanz ermöglicht inkonsistente und damit falsche Da- 
teninhalte. 

Wir werden in den Kapiteln 5 und 6 sehr detailliert behandeln, was diese Datenbasis 
semantisch ist und wie sie konstruiert werden muss. Darüber hinaus wird in Kapitel 
9 auch eine mögliche „Wissensbasis“ aus unstrukturierten Daten angesprochen, in 
der andere Regeln gelten als bei strukturierten Daten. 

Wir beschränken uns im Kontext dieses Buches auf die betriebliche Ressource 
Daten, die für Information und Wissen gleichermaßen eine Basis bildet. Es sei jedoch 
betont, dass eine Organisation aus menschlichen Akteuren besteht, deren kollektives 
implizites Wissen zum expliziten der Datenbasis hinzu kommt, will man vom Wissen 
eines Unternehmens insgesamt sprechen. Nur diese beiden Bestandteile zusammen 
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können organisationales Wissen sein, das es ganz offensichtlich gibt (Willke, 2004). 
Dies aber ist Gegenstand der betrieblichen Personalwirtschaft und der Soziologie. 

4.3.3 Wissen, abschließend betrachtet 

Wir errichten zum Begriff Wissen keine Hierarchie, wie dies in der semiotischen Tra- 
dition geschieht, in der Form Zeichen ^ Daten ^ Information ^ Wissen (Mertens 
et al., 2005, 53), sondern stellen Wissen neben die Information, wie Abb. 4.4 es zeigt. 
Allerdings ist das Bild nur mit der Beschriftung richtig zu lesen, denn es gibt sowohl 
Information als auch Handlungskompetenz ohne die Grundlage Daten, nämlich auf 
der Basis impliziten Wissens. Wenn ein Akteur eine Nachricht schon „weiß“, kann 
sie keine Information sein. Sie gehört aber zu seinem Wissen. Stellt er dieses Wissen, 
das wahrscheinlich über die Nachricht hinaus implizite Bestandteile hat, als Daten 
den übrigen Organisationsmitgliedern zur Verfügung, hat er in der Datenbasis das 
organisationale Wissen erweitert. Wir halten abschließend fest: 




Abb. 4.4. Die formalen Bestandteile von Wissen und Information 



Wissen ist wegen seiner impliziten Bestandteile ebenso individualisiert wie In- 
formation. Explizites Wissen basiert auf Daten. Implizites Wissen kann explizit ge- 
macht werden, wenn wir über einen allgemein verstehbaren Formalismus zur Be- 
schreibung verfügen. Der Unterschied zur Information ist die Handlungskompetenz 
und die mehrfache Verwendbarkeit der zu Grunde liegenden Daten, die im Allge- 
meinen nur einmal (individuelle) Information sein können. 

Zusammenfassung Abschnitt 4.3 

o Wissen hat implizite und explizite Bestandteile. Letztere werden in Form 
von Daten abgebildet. 

Die kreative Benutzung von Daten beruht auf implizitem Wissen und 
Können. Der Bereich Können oder auch Handlungskompetenz ist Ge- 
genstand der Personalwirtschaft. 



o 







4.4 Wiederholung 



51 



o Der explizite Teil des Wissens wird in der Informationswirtschaft mittels 
der Teilfunktion Datenmanagement verwaltet, 
o Organisationales Wissen besteht aus den Daten einer Organisation zu- 
züglich des impliziten Wissens ihrer Mitglieder. 



4.4 Wiederholung 

• Kommunikation erfolgt über Kanäle in Form von Nachrichten. Die informations- 
wirtschaftlich relevanten Nachrichten haben die Form codierter Daten. An dieser 
Art von Kommunikation sind Automaten beteiligt. 

• Die zwischenmenschliche Kommunikation ist ein Thema der Personalwirtschaft. 

• Kommunikation zwischen Automaten erfordert Protokolle. 

• Besonders interessant sind höhere Protokolle zwischen automatisierten Anwen- 
dungen. 

• Informationen sind Nachrichten, die für den Empfänger neu, relevant und ver- 
ständlich sind. 

• Es gibt Informationen zwischen Automaten. Sie müssen zwingend einmalig sein, 
was technisch gewährleistet werden kann. 

• Gleich verstehbare Information an Kollektive kann im nicht trivialen Fall nur aus 
strukturierten Daten stammen. 

• Wissen kann, gestützt auf systematisch gepflegte Daten, eine wichtige Unter- 
nehmensressource sein. Allerdings darf dabei die personelle Seite des impliziten 
Wissens nicht vernachlässigt werden. 

• Wissen ist Handlungskompetenz und nicht lexikalisches „Wissen“. Dies sind Da- 
ten. 
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Die Inhalte betrieblicher Daten 



In diesem Kapitel werden diejenigen Daten besprochen, die wir als Ressource Da- 
ten bezeichnet hatten. Am Beispiel des Industrieunternehmens wird gezeigt, welche 
Objekttypen dies sind und aus welchen wesentlichen Attributen sie bestehen. Dabei 
wird es sich als notwendig erweisen, Fragen nach der Struktur von Daten zu stellen, 
weil wir Strukturen der Realwelt abbilden müssen. Dies wird allerdings noch intuitiv 
geschehen, da in diesem Kapitel die betriebswirtschaftliche Semantik der Daten im 
Vordergrund steht und nicht formale Fragen. 



5.1 Klassifikation betrieblicher Daten 

Zwar lässt sich die Vielfalt betrieblicher Daten über alle Branchen nicht allgemein 
behandeln, es ist jedoch möglich, ein Referenzmodell für den ln der Betriebswirt- 
schaftslehre am häufigsten zu Grunde gelegten Unternehmenstyp anzugeben, den 
Industriebetrieb. Dies wird - entsprechend der Zielsetzung dieses Buches - erheb- 
lich einfacher und auch mit stärker generalisierten Inhalten geschehen als das Scheer 
(1997) getan hat. 

Ein fruchtbarer Blick auf betriebliche Daten kann nur gelingen, wenn man in die 
Vielfalt betrieblicher Informationen eine Struktur bringt, die überschaubar ist und 
dauerhaft Bestand hat. Scheer analysiert für sein Entwurfskonzept ARIS unter meh- 
reren Blickwinkeln: Organisation, Eunktion und Daten. Dies erscheint für Anfänger 
erheblich zu komplex. Wir suchen zunächst auch kein Entwicklungskonzept, sondern 
ein Ordnungsschema. Andere Versuche, die Daten des Industriebetriebs systematisch 
zu betrachten, konnten in Lehrbüchern nicht gefunden werden. 

Ein Ansatz für eine Klassifikation, die sich implizit auf Daten bezieht, ist die 
Einteilung in Grund- und Sonderrechnung von Schmalenbach (1963) (s. auch We- 
dekind, 1979). Die Grundrechnung müsse, so Schmalenbach, dauerhaft stabil blei- 
ben, unabhängig davon, welche Änderungen das Unternehmen im Laufe der Zeit 
durchmacht. Aus der Grundrechnung könne man dann beliebige Sonderrechnungen 
erzeugen, die auch über lange Zeiträume strukturstabil sind, wenn sie sich auf die 
Grundrechnung abstützten. Eür unsere Zwecke scheint eine analoge Klassifikation 
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in originäre und abgeleitete Daten zweckmäßig, die genau der Schmalenbachschen 
Intention entspricht. Sie wurde unseres Wissens erstmals auf einer Fachtagung von 
Hasso Plattner (1981) gebraucht, einem der vier Gründer der SAP AG. Eine fast 
gleichnamige Unterscheidung, die (Ferstl & Sinz, 2001, 142) treffen, hat eine andere 
Semantik, die in der Struktur von Daten begründet ist. Wir werden sehen, dass unse- 
re Klassifikation es ermöglicht, einen trennscharfen Überblick über die betrieblichen 
Daten zu bekommen. 

Originär sind diejenigen Daten, die an einer Quelle entstehen. Der Datenur- 
sprung ist meist der Betrieb selbst, noch konkreter: Menschen, gelegentlich auch 
Messdaten von Maschinen. Seltener stammen originäre Daten aus der Umwelt des 
Unternehmens, z.B. (gekaufte) Marktdaten. Die originären Daten dienen der gera- 
de erwähnten Grundrechnung, haben aber für sich noch keinen nennenswerten Nut- 
zen. Dieser entsteht erst dwxch abgeleitete Daten, die Schmalenbachsche Sonderrech- 
nung. Für diese Kategorie werden heute nicht Daten, sondern Programme gepflegt, 
denn sie werden ausschließlich berechnet. Schon Schmalenbach warnt davor, für 
nicht zu befriedigende Informationsbedürfnisse die Grundrechnung zu verändern. 
Hierzu hält er Behelfsrechnungen bereit. 

Bereits die Klassifikation von Schmalenbach könnte ganz grob mit dem Begriffs- 
paar Daten - Information gleichgesetzt werden. Hier ist sie Konzept, wenn auch mit 
der Einschränkung, dass originäre Daten ebenfalls Informationen sein können. Die 
sorgfältig zu pflegenden Daten als betriebliche Ressource werden von der Vielfalt 
daraus ableitbarer Informationen getrennt. Abb. 5.1 zeigt in einer oft benutzen Dar- 
stellung den Grundaufbau betrieblicher Daten, ergänzt um die gerade erwähnte Un- 
terscheidung. Nach Sinz (1983) kann man nur dann von einem integrierten Daten- 
system sprechen, wenn das System der Daten hierarchisch konsistent ist. Dies soll 
mit der Pyramide zunächst informell ausgedrückt werden. 
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Abb. 5.1. Verdichtungsebenen betrieblicher Daten 



Die Pyramide zeigt sowohl eine Zuordnung der verschiedenen betrieblichen Soft- 
waresysteme, Anwendungssysteme genannt, zu Management-Ebenen, als auch die 
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von der Basis nach oben zunehmende Verdichtung der Daten. Verdichten bedeutet 
im betrieblichen Kontext häufig addieren. So werden etwa für das Führungsdatum 
Umsatz2 004 bei einem Warenhauskonzern hunderte Millionen von Einzelverkäu- 
fen zu einer Zahl addiert, dem Gesamtumsatz. Ebenso gehören Bilanz und Gewinn- 
und Verlustrechnung (GuV) zu den Summendaten an der Spitze. Wir sprechen, um 
auch Kennzahlen in den Führungssystemen mit einzubeziehen, von aggregierten Da- 
ten. 

Für die administrativen Systeme in Abb. 5.1 wird heute auch in der Wissenschaft 
der industrieübliche Begriff Operative Systeme benutzt (Mertens et al., 2005, 84). 
Dies sind die Softwaresysteme, die die betrieblichen Funktionen aus Kapitel 2 unter- 
stützen oder steuern. Wir betrachten in diesem Kapitel die zugehörigen originären 
Daten, von ihnen wiederum nur die Istdaten der Routinevorgänge, die sie steuern- 
den Grunddaten (zusammen die administrativen Daten) und genau zwei Typen von 
Bestandsdaten. Für Grund-, Vorgangs- und Bestandsobjekttypen werden die Abkür- 
zungen GOT, VOT und BOT verwendet. Mit Vorgang bezeichnen wir im Kontext 
dieses Buches meist einen Routinevorgang. Die Planungsdaten sind überwiegend 
Gegenstand der betrieblichen Funktion Controlling. 

Die Vielfalt der abgeleiteten Daten werden wir nur an Hand einiger wichtiger 
Beispiele behandeln. 



5.2 Originäre und abgeleitete Daten 

In Abschnitt 2.3.2 hatten wir von einer „Spur“ gesprochen, die betriebliche Prozesse 
in Form von Daten hinterlassen. Dies sind die Aufzeichnungen der Geschäftsvorfälle 
und einiger Hilfstätigkeiten, die den größten Teil der originären Daten bilden. Wie 
in einem Zettelkasten wird notiert, wann ein Vorgang mit welchen quantifizierten 
Größen (Mengen oder Werte) stattgefunden hat oder stattfinden soll. Wir hatten diese 
Art von Daten bereits Vorgangsdaten genannt. 

Wollen wir entscheidungsrelevante Informationen über Vorgänge haben, werden 
wir nicht der Vielzahl der Einzelfälle und deren vielleicht zufälligen Ausschlägen 
folgen, sondern die Daten verdichten, indem wir mit simplen Rechenoperationen 
(addieren, Durchschnitte und sonstige Quotienten bilden, zählen. Minima und Maxi- 
ma ermitteln) abgeleitete Daten erzeugen. Dies erfolgt durch Programme, weshalb 
abgeleitete Daten niemals von Benutzern in elektronische Speicher geschrieben wer- 
den dürfen, sondern nur durch Programme. Im einfachsten Pall sind Pehler die Polge, 
es wären aber auch Manipulationen möglich. 

Jeder Wert in einer Bilanz ist ein hoch verdichtetes, abgeleitetes Datum. Man 
wird kein seriöses betriebliches Anwendungssystem finden (mehr in Kapitel 7), in 
dem es Eingabemöglichkeiten für abgeleitetete Daten gibt. Solche Daten sind z.B. 
Warenbestände. Sie verändern sich durch die (originären) Vorgangsdaten Zu- und 
Abgangsbuchungen. Jeder Wirtschaftsprüfer wird die Vorgänge prüfen, nicht die ab- 
geleiteten Daten. 

Zum besseren Verständnis noch ein einfaches Beispiel aus dem Handwerker- 
Bereich: 
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Ein Handwerker will Mitte November wissen, ob er seine Umsatz-Ziele in diesem 
Jahr erreichen wird. Ohne Computersystem wird er die Endbeträge aller verschickten 
Rechnungen addieren. Er kann sich den Rechenstreifen seiner Additionsmaschine in 
den Ordner mit den Rechnungen legen, damit er am Jahresende nicht die gesamte 
Arbeit wiederholen muss. Dieser wird ihm aber nur dann etwas nützen, wenn sich an 
den schon in der Summe enthaltenen Rechnungen etwa durch Reklamationen nichts 
mehr ändert. Am Jahresende wird er einen Buchungsschluss machen müssen, bevor 
er irgend welche Daten etwa an den Steuerberater oder das Finanzamt weiter gibt. 

Der Buchungsschluss bewirkt, dass er keine originären Daten (seine Rechnungen) 
mehr ändern darf. 

Die Unterscheidung zwischen originären und abgeleiteten Daten hat sehr viel 
mit den Grundsätzen ordnungsgemäßer Buchführung (GoB) zu tun (vgl. z.B. Wö- 
be et al., 2002), und zwar mit dem Grundsatz der materiellen und formellen Ord- 
nungsmäßigkeit (§ 238ff HGB). Dieser bestimmt, dass jeder Vorgang durch Dritte 
nachvollziehbar sein muss, z.B. die Bezahlung einer Rechnung. Früher waren dies 
Originalbelege in Papierform, heute sind dies Vorgangsbuchungen in Form nicht ma- 
nipulierbarer Daten und Originalbelege, etwa Lieferantenrechnungen. Nur wenn alle 
Vorgangsdaten zu den ausgewiesenen abgeleiteten Daten führen, ist ein Geschäfts- 
vorfall nachvollziehbar. 

Neben der Nachvollziehbarkeit kommt allerdings eine technische Komponen- 
te hinzu. Inzwischen haben selbst Handwerker Computer, aus denen heraus sie die 
Rechnungen erzeugen und auch gleich in einer Buchhaltungskomponente speichern. 
Der „Zettel im Ordner“ (s. oben) ist unnötig, weil ein heutiger PC fast jedem vorstell- 
baren Handwerker die aktuellen Umsatzinformationen auf Knopfdruck liefern kann. 
Es gibt also zunehmend weniger Gründe, abgeleitete Daten zu speichern. Sie werden 
berechnet, wenn man sie braucht, und sind dann zum Zeitpunkt der Berechnung auch 
richtig. 

Dies trifft für immer mehr abgeleitete Daten zu, aber nicht für alle. In mittleren 
und großen Unternehmen führen Millionen von Vorgängen zu wenigen abgeleiteten 
Daten, etwa den Monatsumsätzen je Produkt. Dies ist zur Zeit (2006) und abseh- 
bar für die nächsten 10 Jahre synchron (also im Dialog) nicht möglich, sondern nur 
asynchron, da die Rechenzeit solcher Aggregationen im Minuten- bis Stundenbe- 
reich liegen kann. So benötigt die Absatzstatistik eines Versandhandels weit über 10 
Stunden Laufzeit. Dies führt dazu, dass bestimmte abgeleitete Daten unter genau de- 
finierten Bedingungen doch gespeichert werden müssen. Für umfassende informati- 
ve Datenbestände dieser Art werden heute sog. Data-Warehouse-Systeme eingesetzt 
(vgl. etwa Dippold et al., 2005, Kap. 9). 

Eine Sonderrolle unter den abgeleiteten Daten nehmen die Bestandsdaten ein. 
Wir definieren, anders als (Mertens et al., 2005, 55): Bestandsdaten sind abgeleitete, 
synchron mit Vorgängen gespeicherte Daten. Es muss gewährleistet sein, dass sie 
durch geeignete Änderungsoperationen immer konsistent mit den ihnen zu Grunde 
liegenden Vorgangsdaten sind, mit anderen Worten, ihre Aktualisierung muss mit der 
Buchung der Vorgänge eine Transaktion (s. Abschnitt 2.3.3) bilden. Nur für genau 
diesen Fall benutzen wir den Begriff Realtime. Darunter versteht man die synchrone 
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Buchung mehrerer Datenbestände in einer Transaktion. Das SAP-System R/3 ® hat 
seinen Namen daher. ’R’ steht im Realtime (s. Plattner (1981)). 

So sind etwa Waren- und Materialbestände in Firmen mit vielen Lägern und weit 
verteilten Standorten als (abgeleitete) dispositive Daten zentral gespeichert. Sie müs- 
sen allerdings durch jede Zu- und Abgangsbuchung automatisch aktualisiert werden. 
Man braucht diese summarischen Bestände für dispositive Zwecke, etwa bei einer 
Verfügbarkeitsprüfung, die der Kunde im Internet online (also synchron) erwartet. 
Nur mit diesem Wissen kann die oft zitierte Informationspyramide aus Abb. 5.1 rich- 
tig verstanden werden. Auch Soll- und Flabenbuchungen in der Buchhaltung bilden 
je Buchungssatz eine Transaktion und werden am Periodenende zu Bestandsdaten 
saldiert. 

Niemals durch menschliche Akteure, sondern immer durch Programme werden 
abgeleitete Daten erzeugt. Deshalb muss kurz über Programmieren gesprochen wer- 
den. 



Exkurs Programmieren 

Das Schreiben von Computerprogrammen ist nicht Gegenstand dieses Buches. Trotz- 
dem ließ es sich nicht vermeiden, Daten und Programme zu unterscheiden. Es soll 
kurz erklärt werden, was ein Programm ist. 

Üblicher Weise werden Programme in einer formalen Sprache geschrieben, etwa 
COBOL, Pascal oder Java. Tabelle 5. 1 zeigt einen Programmbaustein, Prozedur oder 
auch Methode genannt, der einen Text auf den Bildschirm schreibt. Der Leser soll 
durch das Beispiel einen wenigstens intuitiven Eindruck bekommen, was formal be- 
deuten könnte: Es gibt sehr rigide, in jeder Programmiersprache andere syntaktische 
Regeln, die genau eingehalten werden müssen, wenn ein Computer das Programm 
ausführen soll. 



Tabelle 5.1. Ein Programmbaustein in drei Programmiersprachen 



COBOL 


Pascal 


Java 


Meldung. 

Display ’hallo’. 


procedure meldung; 
begin 

writeln( ’hallo’); 
end; 


void Meldung ( 
System.out.println(’hallo’); 

} 



Auch ohne weitere Erklärungen zur Syntax wird der Leser eine Vorstellung da- 
von bekommen, was Programme sein könnten, die in der Realität aus Tausenden von 
Befehlen bestehen. Die Programmstücke führen in allen drei Beispielen nur einen 
Befehl aus, der die Zeichenkette 'hallo' auf den Bildschirm schreibt. Die restli- 
chen Wörter sind Erfordernisse der jeweiligen formalen Sprache. Ein realistischeres, 
aber für unsere Zwecke schon zu umfangreiches Programm würde eine Nachricht be- 
liebigen Inhalts aus einer Datenbank lesen, die getrennt vom Programm gespeichert 
ist. Diesen Aspekt werden wir in Kapitel 9 wieder aufgreifen. 
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Abb. 5.2. Programm Tabellenkalkulation mit einer Summe 



Viele Leser werden ein Programm wie in Tabelle 5.1 noch nie gesehen oder 
geschrieben haben. Sie werden aber sehr wohl eine Tabellenkalkulation aus einem 
Office-System kennen. Bei ihr sind Befehle und Daten miteinander vermischt. Viele 
Befehle „schreibt“ man durch Anklicken. In einfachen Fällen erkennt das System 
automatisch, auf welche Daten man eine Operation anwenden möchte, z.B. beim 
Summieren einer Zeile oder Spalte. In komplizierteren Fällen muss man sie in Form 
sogenannter Bezüge eingeben. Auch dies ist Programmieren. Es ist gerade bei der 
Erstellung abgeleiteter Daten einfacher Art sehr verbreitet. 

Doch so einfach es ist, diese Art des Programmierens zu lernen, so leicht kann 
man damit auch Eehler machen. Wenn wir annehmen, dass die originären Daten rich- 
tig eingegeben wurden, liegt die Quelle für Eehler bei abgeleiten Daten, unabhängig 
davon, wie programmiert wird, nur in den Programmen. Bei der Tabellenkalkulation 
sind die Eehlerquellen falsche Bezüge oder falsch benutzte Punktionen. Es können 
auch versehentlich Pormeln durch originäre Daten überschrieben werden, da fast 
niemand die Möglichkeit des Schutzes der Zellen mit abgeleiteten Daten kennt. 

Zusammenfassung Abschnitt 5.2 

o Originäre Daten sind diejenigen Daten, die in einer Organisation durch 
menschliche Entscheidungen oder technische Messung „am Ursprungs- 
ort“ entstehen. 

o Abgeleitete Daten sind aus originären durch Berechnungen ermittelte 
Daten. Sie ändern sich so lange, wie die ihnen zu Grunde liegenden ori- 
ginären Daten änderbar sind. Da abgeleitete Daten nur durch (Rechen)- 
Operationen entstehen und nicht durch menschliche Entscheidungen, 
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darf es niemals möglich sein, sie (originär) über Bildschirme oder sons- 
tige externe Medien (auch nicht über Datenbestände) in eine Datenbasis 
einzubringen. 

o Umgekehrt sind Daten von Führungs- oder dispositiven Systemen nur 
korrekt, wenn sie auf originären aufbauen. Auf diesem „Gesetz“ beru- 
hen die Grundsätze ordnungsgemäßer Buchführung und ähnliche Regel- 
werke anderer Länder. 

o Bestandsdaten sind synchron mit Vorgangsdaten geänderte, abgeleitete 
Daten, die aus technischen oder betriebswirtschaftlichen Gründen ge- 
speichert werden. 

o Fehler in abgeleiteten Daten können nur Fehler in Programmen sein. 

o Planungsdaten werden häufig geschätzt; dann sind sie originäre Daten. 

Sie können aber auch auf Berechnungen beruhen; dann sind sie disposi- 
tive Daten (vgl. Abb. 5.1). In diesem Fall sind die den Rechenverfahren 
zu Grunde liegenden Daten und Parameter die originären Daten. 



5.3 Betriebliche Daten im Überblick 

Wir werden in den folgenden Abschnitten dieses Kapitels die wichtigsten origi- 
nären Daten detailliert besprechen. Dabei sparen wir den Bereich Produktion weit- 
gehend aus, da er für eine Einführung zu schwierig ist. Erstens sind die Grund- und 
Vorgangsdaten wegen der Vielfalt industrieller Produktionsformen schlecht genera- 
lisierbar und zweitens verlangen sie vom Leser eine Vorstellung von industrieller 
Eertigung, die bei Anfängern nicht vorausgesetzt werden kann. Die handwerkliche 
Baumarkt-Metapher führt hier zu falschen Analogien. 

Mit Tabelle 5.2 geben wir eine Vorschau und Orientierungshilfe. Sie zeigt links 
die verschiedenen Arten von Daten, grob gegliedert in die Klassen der beiden vor- 
angehenden Abschnitte. Die unterste Ebene, im Singular benannt, sind die wichtigs- 
ten Datenobjekttypen, die in den folgenden Abschnitten besprochen werden. In der 
Zeile oder Eolgezeile zu jedem Objekttyp werden in der rechten Spalte der Tabelle 
Beispiele oder charakteristische Eigenschaften der Objekttypen genannt. 
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Tabelle 5.2. Überblick betriebliche Daten 



Art der Daten / Objekttyp Eigenschaften und Erläuterungen 



Originäre Daten 


Grunddaten (GOT) 


Dauerhaft bis langlebig; unabhängig von Vorgängen 


I. Sachanlagen 


Datentypen Kontenklasse 0 ohne immat. und Einanzanlagen 


Gebäude 




Grundstück 




Anlage (Arbeitsplatz) 




II. Operative Grunddaten 




Produkt 


Tief gestaffelte, hierarchische Rollen 


Kunde 


Synonym Debitor 


Lieferant 


Synonym Kreditor 


Mitarbeiter 




Kontenplan 


einfacher, aber wichtiger GOT 


Lager 


In einfachen Eällen nur Kategorie 


III. Kategorien 


Sog. Schlüssel oder Codes; meist in Form von Abkürzungen, 




die zur Sprachkultur jedes Unternehmens gehören; Merkmale 




zur Klassifizierung dispositiver und informativer Daten 


Werk 




Sparte 




Kostenstelle 




Marke u.v.a.m. 




Vorgangsdaten (VOT) 


Zeitpunkt-bezogen; abhängig von Grunddaten; Flussgröße 




in Prozessen; Grundlage abgeleiteter Daten; meist als Struktur 




Komposition. 


Verkaufsbeleg 


z.B. Angebot, Auftrag, Rechnung 


Einkaufsbeleg 


z.B. Bestellung, Abruf, Rechnung 


Leistung 


Häufig gesteuert von Arbeitsplan 


Bewegung 


Meist als Lagerbewegung 


Buchung 


Mit Integritätsbedingungen der Doppik 


Abgeleitete Daten 


Bestandsdaten (BOT) 


Zwingend realtime aus Vorgängen gebucht 


Lagerbestand 


Je Werk /Lager /Artikel, gespeist aus Bewegungen 


Konto 


Gemäß Kontenplan, gespeist aus Buchungen 


Dispositive Daten 


Durch Programme ermittelte oder Plandaten 


Bedarf 


Für Material- und Produktionsplanung 


Budget u.a. 


Soll-Vorgaben je Kostenstelle oder ähnliche Pläne 


Informative Daten 


Zeitraum-bezogen 


Bilanz 


Nach HGB oder International Financial Reporting Standards 


GuV 


Gewinn- und Verlustrechnung 


Kosten 


Kostenstellen - Soll-/Ist- Vergleich 


Absatz 


Mengen je Produkt /Region etc. 


Umsatz u.v.a.m. 


Werte je Produkt /Region etc. 
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5.4 Grunddaten 

Grunddaten (auch Stammdaten) sind das datenmäßige Abbild der betrieblicher Res- 
sourcen, Objekte und Subjekte, die über lange Zeiträume abgebildet werden. Sie 
steuern alle betrieblichen Vorgänge, die datenmäßig aufgezeichnet werden. Wir tei- 
len sie in drei Gruppen, die im Detail besprochen werden. Die Grunddaten I und 
II sind in fast allen Fällen komplex strukturiert, während die Grunddaten III sehr 
einfach sind. 

5.4.1 Sachanlagen (Grunddaten I) 

Nur die Grunddaten I entsprechen dem üblichen betriebswirtschaftlichen Ressour- 
cenbegriff, während die Grunddaten 11 kurzfristiger zu sehen sind. Die Grunddaten 
I eines Industrieunternehmens sind: 

o Gebäude und Grundstücke 
o Anlagen und Arbeitsplätze 

Sie sind ein Abbild des Produktionsfaktors Betriebsmittel, der Zu- oder Abgang eine 
Investition bzw. Desinvestition. Als typisches Beispiel wollen wir den Grundobjekt- 
typ Anlage diskutieren. Er wird von der Funktion Anlagenbuchhaltung (vgl. Tabelle 
2.1) verwaltet und der Kontenklasse 0 der Buchhaltung zugeordnet. 

Um zu verstehen, wie ein Objekttyp im Detail definiert ist, müssen wir uns seine 
Attribute ansehen, die seine Eigenschaften abbilden. Von ihnen werden bei einer 
Anlage festgehalten:' 

Anlage {AnlagenNr, Bezeichng, Anschaf fDat, InBetriebDat , 
Anschaf f Preis , Standort, AbschreibungsKls , Ausser- 
BetriebDat) 

Wenn man den Datentyp so modelliert, unterstellt man, dass sich das Abschrei- 
bungsverfahren über die Lebensdauer der Anlage nicht ändert, denn wir haben die 
AbschreibungsKlasse wie etwa das InBetriebnahmeDatum als Eigen- 
schaft einer Anlage (= eine Tabellenzeile) modelliert. Wenn aber der Gesetzgeber 
zur Ankurbelung der Konjunktur Sonderabschreibungen einführt, könnte diese Mo- 
dellierung sich als zu einfach erweisen. Es ist nicht möglich, verschiedene zeitabhän- 
gige Daten in einem Grunddatentyp einfacher Struktur festzuhalten, da der Grund- 
datentyp selbst Zeit-unabhängig ist. Einen Zeitbezug braucht man aber, wenn das 
Abschreibungsverfahren während der Lebensdauer der Anlage geändert werden soll. 
Eine Ergänzung des Objekttyps um einen zeitabhängigen Datentyp könnte so ausse- 
hen: 

AnlagenZustand {AnlagenNr, StichtagsDat , AbschreibungsKls, 
Stichtagswert) 

* Entsprechend Kapitel 3 sind die mit fettgedrucktem Namen benannten Objekttypen als 
Tabellen zu verstehen. Die Namen in Klammern () sind die Spaltenüberschriften. Man kann 
in Tabellenfelder beispielhafte Werte schreiben, wie man das in einer Tabellenkalkulation 
auch täte. 
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Durch die AnlagenNr wird der Zusammenhang mit dem ursprünglichen Datentyp 
hergestellt. Die AbschreibungsKlasse (linear, progressiv, degressiv etc.) wäre 
dann keine Eigenschaft des Datentyps Anlage mehr, sondern des von ihm abhängi- 
gen Datentyps AnlagenZustand. Wir können also Grunddaten um zeitabhängige 
Daten erweitern, allerdings nur mit zusätzlichen, von den ursprünglichen abhängi- 
gen Tabellen. Nur so können wir Daten über „Lebensabschnitte“ eines Objekttyps 
festhalten. 

Wenn wir ein neu erworbenes Anlagegut dem Anlagevermögen zubuchen, gilt es 
als aktiviert. Doch was ist „das“ Anlagegut? Hierzu zwei Beispiele: 

1. Die Aktivierung einer neuen Büroausstattung, bestehend aus einem Schreib- 
tischstuhl, zwei Schränken und einem Schreibtisch dürfte keine Probleme be- 
reiten. Je Element erhalten wir in einer Datentabelle Anlage eine neue Zeile. 

2. Nun soll ein Personalcomputer dazu kommen, bestehend aus Bildschirm, Tasta- 
tur, Maus und Desktop. Was ist jetzt das Anlagegut PCI Wenn einzeln gebucht 
wird, fehlt die Möglichkeit, die technische Zusammengehörigkeit der Bestand- 
teile zu buchen. Hierfür ist die modellierte Tabelle zu einfach. 

Die Lösung des Strukturproblems, dass eine Anlage aus identifizierbaren Teil- 
Anlagen besteht, werden wir bei den Grunddaten II am Beispiel von Stücklisten 
kennen lernen. 

5.4.2 Operative Grunddaten (Grunddaten II) 

Bei den Grunddaten II ist das einzelne Exemplar teilweise kurzlebiger, begegnet 
uns aber im Routinebetrieb ständig in der Gestalt von Objekten (z.B. Produkten) 
oder Subjekten (z.B. Mitarbeiter). Wir geben zunächst eine Übersicht über Rollen 
und Synonyme der wichtigsten Grunddaten II, das sind Produkt, Kunde, Lieferant, 
Mitarbeiter und Lager: 

Produkt (Teil, Erzeugnis, Baugruppe, Zwischenprodukt, Ersatzteil, Material, Ver- 
packungseinheit) 

Kunde (Regulieren Auftraggeber, Debitor, Niederlassung, Liliale, Rechnungs- und 
Warenempfänger) 

Lieferant (Kreditor, Zulieferer, Zwischenmeister, Lohnveredler) 

Mitarbeiter (Angestellter, Arbeiter, Manager, Außendienst-Mitarbeiter) 

Lager (Gebäude, Gebäudeteil, Teil eines Raumes (Halle), Ebene, Stellplatz) 

Die Grunddaten II haben einen klaren Bezug zu der einleitenden Abb. 1 . 1 des Ge- 
samtunternehmens. Alle fünf Objektypen korrespondieren mit dem Materialfluss, 
dem Geldfluss und den Beziehungen des Unternehmens zur Umwelt. Sie sind häufig 
hierarchisch gegliedert, das Produkt immer. 

Am Beispiel des Grundobjekttyps Produkt und seiner Attribute Marke, Dirnen - 
sion und Preis werden wir jetzt folgende Fragen klären: 

1. Rollen eines Produkts: Wie stellt man eine Objekthierarchie dar? 

2. Stückliste: Wie werden Bäume abgebildet, wenn die Kanten Eigenschaften ha- 
ben? 
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3. Marke, Dimension: Wie bilden Aufzählungstypen die Realität am besten ab? 

4. Preise: Wie kann ein Attribut je nach betriebswirtschaftlicher Semantik Objekt- 
typen zugeordnet werden? 

Davor eine kurze Begriffsklärung. Graphen sind Zeichnungen aus Knoten (o) 
und Kanten (-). Sie können alle denkbaren Formen haben. Die Form in Abb. 5.3 für 
eine Hierarchie nennt man Baum. 




Abb. 5.3. Ein Graph in der Form Baum 



Rollen in einer Objekthierarchie (Knoten von Graphen) 

Als besonders wichtiges Beispiel für die komplexe Struktur der Grunddaten zeigt 
Abb. 5.4 den Objekttyp Produkt, abstrahierend auch Teil genannt. Der Begriff Teil 
ist gegenüber der Rolle Material semantisch neutraler als „Produkt“. 




Abb. 5.4. Rollenhierarchie Grundobjekttyp Produkt (Teil) 



Wir werden jetzt Teil mit seinen Rollen und wichtigsten Attributen entwickeln. 
Bei Teil befassen wir uns mit dem dominierenden Grundobjekttyp jedes Industrie- 
unternehmens, der das Funktionieren der Grundfunktionen Beschaffung, Produktion 
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und Absatz bestimmt. Wohl definiert und sorgfältig gepflegt, ist er ein wichtiger 
Erfolgsfaktor für die Logistik, vor allem bei breitem Produktspektrum und schneller 
Folge von Produktversionen. Die Grunddaten zum Objekttyp Teil entstehen im Ge- 
schäftsprozess Produktgestaltung bzw. -entwicklung (s. Abb. 2.6, Seite 16). Schlecht 
gepflegte Produktdaten sind eine Quelle für Kosten treibende Störungen der Routine- 
abläufe. Besonders wichtig werden die Produkt-Grunddaten bei kundenindividueller 
Fertigung von Varianten, etwa bei Autos oder Möbeln. Aber auch im Handel, ein 
wichtiger Kunde der Konsumgüterindustrie, spielt das Produkt eine dominierende 
Rolle (s. Becker & Schütte, 2004). 

Wir konkretisieren Abb. 5.4 mit beispielhaften Daten. Tabelle 5.3 zeigt einen 
Objekttyp Teil, in dem die Rollen Gebinde, Set, Artikel, Baugruppe, Einzelteil 
und Material als Abkürzungen angegeben sind. Die Attribute Rolle, Marke und 
Dimension sind Aufzählungstypen. Im oberen Teil der Tabelle sind einfache Bei- 
spiele aus einem Verbrauchermarkt, im unteren ein Automobil mit einer Baugruppe 
und einigen Einzelteilen eingetragen. 



Tabelle 5.3. Beispiele von Produktdaten verschiedener Rollen 



Teil 

TeilNr 


Rolle 


Bezeichnung 


Marke 


Preis 


Dimension 


471 


Geb 


Sockenmischung Wolle 


nur die 


200,00 


St 


237 


Set 


Bindedraht ummantelt 


- 


9,50 


St 


478 


Art 


Wollsocke 


nur die 


2,99 


Paar 


210 


Mat 


Karton 10x50x20 


nur die 


0,43 


St 


239 


Art 


Bindedraht grün 


- 


1,20 


m 


241 


Mat 


Etikett, selbstklebend 


- 


0,07 


St 


101 


Art 


Polo IV 


VW 


12562,00 


St 


172 


Bg 


Rad, Sommer 


VW 


107,30 


St 


716 


Ein 


Felge 


VW 


29,70 


St 


912 


Ein 


Radmutter 


VW 


0,52 


St 


181 


Mat 


Reifen 165/70 


Conti 


32,80 


St 


175 


Bg 


Rad, Sommer 


VW 


102,10 


St 


797 


Mat 


Reifen 165/70 


Firest 


31,20 


St 



Stücklisten (Kanten von Graphen) 

In vielen Software-Eigenentwicklungen von Unternehmen wurden die Datentypen 
der Produktion und des Absatzes nicht in der durchgehenden Form von Abb. 5.4 
gesehen. Dies hatte zur Folge, dass getrennte Programmsysteme für Material und 
Fertigerzeugnisse entstanden. Hierdurch wurde eine gängige Dispositionsrechnung, 
die Bedarfsermittlung mit Stücklistenauflösung unmöglich gemacht. Abb. 5.4 ist, mit 
konkreten Werten gefüllt, eine Stückliste. Sie erlaubt es, den Material- oder Baugrup- 
penbedarf für eine vorgegebene Menge von Verkaufseinheiten zu errechnen oder die 
Herstellkosten eines Produktes zu ermitteln {Kalkulation). 
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a) anschaulich, aber redimdant b) kompakt, weil rekursiv 

Abb. 5.5. Grafische Darstellungen einer Stückliste 



Wir haben mit Tabelle Teil nur die Knoten des Graphen abgebildet. Was noch 
fehlt, sind die Kanten. Hierfür benötigen wir eine zweite Tabelle, da die Menge, mit 
der ein untergeordnetes Teil in einem übergeordneten enthalten ist, in gar keinem 
Fall eine Eigenschaft des Objekttyps Teil sein kann. Hierfür wird ein Objekttyp 
Stückliste gebraucht, der zwei Exemplare des Grundobjekttyps Teil miteinan- 
der verbindet, das übergeordnete (Rolle Ober) und das untergeordnete (Rolle Unter). 
Zeichnerisch ist dies in Abb. 5.5 ausgedrückt, wobei die Variante b) allgemein be- 
vorzugt wird, weil sie klarer macht, dass es nur einen Objekttyp gibt und nicht zwei. 
Die Rollen sind in Abb. 5.5b) dicht an den Objekttyp auf der entgegengesetzten Seite 
der Assoziation (enthält) geschrieben. Die Leserichtung ist durch einen Pfeil ange- 
geben. Man beachte, dass die Bezeichnung der Assoziation unter der Kante steht, 
wenn man den rechten Entitätstyp Teil aus Teilbild 5.5a) durch Drehung über den 
linken legt. Fragen zur genauen zeichnerischen Notation werden wir erst in Kapitel 
6 vertiefen. 



Tabelle 5.4. Stückliste zur Tabelle Teil 



Stückliste 

Ober.TeilNr 


Unter.TeilNr 


Menge 


471 


478 


50 


471 


210 


1 


237 


239 


5 


237 


241 


1 


101 


172 


4 


172 


716 


1 


172 


181 


1 


172 


912 


4 


175 


716 


1 


175 


912 


4 


175 


797 


1 



Tabelle 5.4 zeigt die Stücklisten der drei folgenden Beispiele: 

1. TeilNr 471 ist ein Karton mit 50 Paar Socken, den der Verbrauchermarkt beim 
Produzenten einkauft, um die Artikel einzeln an die Endverbraucher weiter zu 
verkaufen. Für den Produzenten ist der Karton ein Material (TeilNr 210), das ge- 
eignet beschriftet sein muss. Der Produzent täte gut daran, neutrale Kartons ein- 
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zukaufen und noch ein zusätzliches Material zu verwenden, nämlich ein selbst 
klebendes Etikett mit Markenbezeichnung, Stückzahl und Barcode, das in sei- 
nen Daten gemäß Tabelle 5.3 aber fehlt. (Das Etikett TeilNr 241 lässt sich hier- 
für nicht verwenden.) 

2. TeilNr 237 ist das Set von fünf Rollen Bindedraht (TeilNr 239). Es wird von 
einem selbst klebenden, stabilen Etikett (TeilNr 241) zusammen gehalten. 

3. TeilNr 101 ist die Andeutung der Stückliste für ein Auto, das vier Räder, aber 
kein Ersatzrad mehr hat. Ein Rad ist eine Baugruppe (TeilNr 172), die mit ver- 
schiedenen Reifen (TeilNr 181 und 797) bestückt werden kann und mit vier 
Radmuttern (TeilNr 912) befestigt ist. Allerdings ist das Rad mit einem anderen 
Reifen auch eine andere Baugruppe (TeilNr 175). 

Der Leser wird sich beim letzten Beispiel ausmalen können, dass die Tabelle der 
Teile eines Autos sehr groß wird. Entsprechend umfangreich ist die Stückliste. Auch 
das Verfahren der Stücklistenauflösung ist jetzt nachvollziehbar. Zeichnet man sich 
den Baum Auto — > 4 Räder ^ Einzelteile eines Rades auf, sieht man, dass der Bedarf 
an Radmuttern für ein Auto 16 = 4*4 beträgt. 

Es ist am Beispiel des variant bereiften Rades aber auch zu erkennen, dass eine 
derartig hoch redundante Stückliste nicht die endgültige Lösung des Problems sein 
kann. Eine gelbe Karosserie ist nach unserem einfachen Modell eine andere Bau- 
gruppe als eine grüne (oder eine Variante verschieden farbiger Karosserien) und ein 
Rad mit Eirestone-Reifen ein anderes als das mit Continental-Reifen. Die Lösung 
dieses Problems der Variantenstückliste ist jedoch nicht Gegenstand unseres Buches. 
Sie wird in vielen Abhandlungen zur Produktionswirtschaft behandelt. Zur Verdeut- 
lichung ein Zitat aus einer dieser Quellen: 

„Dabei muss man mit vernetzten Produktionsstrukturen, bei denen gleiche Materiali- 
en über verschiedene Zwischenprodukte mehrfach in dasselbe Endprodukt eingehen, 

... rechnen.“ (Kistner & Steven, 2002, 249f) 

Detaillierte datentechnische Lösungen werden von Scheer (1997) und Kurbel (2005) 
behandelt. Es dürfte deutlich geworden sein, dass die Stückliste das Strukturpro- 
blems beim Objekttyp Anlage ebenfalls löst. 

Aufzählungstypen als Attribute 

Tabelle 5.3 (Teil) hat drei weitere Attribute, mit denen sich unter anderem die 
Lösung der Rollen-Hierarchie hinterfragen lässt. Diese Hierarchie kann auch anders 
modelliert werden, was wir hier aber nicht ausführen können. Wir fragen, wie zuvor 
ähnlich beim Typ Anlage: Ist Marke eine Attribut jeder Rolle und ist der Wert für 
alle Rollen gleich? 

Marke ist ein Aufzählungstyp, den wir für das Beispiel kleinteilige Textilien (s. 
Abschnitt 3.4.1) als 

Marke = {nur die, Bellinda, Elbeo, Alpi, 

modelliert hatten. Die Aufzählung kann jederzeit um neue Marken erweitert werden 
und die Kennung ' - ' berücksichtigt den Eall NoName, also kein Markenprodukt. 
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Das wäre für alle Rollen eine korrekte Modellierung, da mehrfach verwendetes Ma- 
terial keine Marke aufweisen und Mehrfachpackungen immer nur eine Marke enthal- 
ten würden. Der betriebswirtschaftliche Grundgedanke einer Marke würde konterka- 
riert, wenn die Marke nicht auch Eigenschaft eines größeren Gebindes wäre, sofern 
es als solches verkauft wird. Mit anderen Worten: Es soll keine Mischkartons ver- 
schiedener Marken geben. Aber auch der sicher sinnvolle Eall einer Transportpalette 
mit Paketen verschiedener Marken für den Endverbraucher könnte die Produkthierar- 
chie nach oben erweitern, da sie sich neutral kennzeichnen ließe. Beim Auto könnte 
sogar ein Rad unter der Marke des Reifenherstellers und nicht des Eelgenverkäufers 
(im Beispiel VW) vertrieben werden. 

Die Modellierung von Marke als Eigenschaft von Teil ist also schlüssig. 
Dimension ist ebenfalls ein Aufzählungstyp, bei dem es allerdings kein neutra- 
les Element geben darf: Jedes Teil muss eine Dimension für Mengenangaben haben, 
damit mit ihnen richtig gerechnet werden kann. 

Was ist ein Preis? 

Ohne Zweifel ist der Preis in einem ökonomischen Kontext eines der wichtigsten 
Merkmale eines Produktes. Seine Semantik ist aber von der Rolle des Teils abhän- 
gig. Als Lösung lassen sich Sammelrollen definieren, die sich je nach Kontext (Ei- 
genfertigung, Zukauf) überschneiden (vgl. Abb. 5.4, Rollen-Hierarchie Produkt): 

Verkaufsteil = {Gebinde, Set, Artikel} 

Produktionsteil = {Baugruppe, Einzelteil} 

Einkaufsteil = {Produktionsteil , Material} 

und auf dieser Basis festlegen: 

Verkauf steil . Preis ist der Verkaufspreis 
Produktionsteil . Preis ist der Standard-Verrechnungspreis 
Einkaufsteil . Preis ist der Einkaufspreis. 

Mit diesen Eestlegungen wäre die Modellierung von Teil in Tabelle 5.3 für die 
beiden Attribute hinreichend genau. Ist sie aber in jedem Eall praktikabel? 

Der „Hersteller“ der Kleintextilien (, der in Wirklichkeit fast alle seine Produkte 
nur verkauft, aber nicht selbst produziert,) hat mit allen Färb- und Größenvarian- 
ten 150.000 Einzelartikel. Kann er eine Preisänderung durch Aktualisierung von 
150.000 Tabellenzeilen bewältigen? Wohl kaum. Er wird PreisGruppen haben 
(s. Tabelle 3.7) die er in einer Preistabelle verwaltet. Sie könnte wie Tabelle 5.5 ge- 
staltet sein. Es wären dann nur noch so viele Preise zu pflegen, wie es Preisgruppen 
gibt. 

Der Preis ist jetzt keine direkte Eigenschaft des Produktes mehr, sondern der Prei s - 
Gruppe. Durch die Preisgruppe haben wir einen sehr großen Wertebereich (Daten- 
typ f loat) in einen anderen, sehr kleinen abgebildet {gruppiert). Eine Gruppierung 
ist die Abbildung einer Menge auf ein neues Element, hier also die Menge der Preise 
<3, 00 € auf die Preisgruppe 1 . 
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Tabelle 5.5. Eine Preistabelle als Beispiel für Gruppierungen 



iPreisGruppe I 


PreisGrp 


Preis 


1 


2,99 


2 


3,99 


3 


5,49 


usw. 





Wir können damit die Diskussion des Attributs Preis noch immer nicht ab- 
schließen. Wie bilden wir Preise ab, die vom Lieferanten abhängig sind? Tabelle 5.6 
zeigt einen vereinfachten Grundobjekttyp Artikel, bei dem wir die Rollen außer 
Acht lassen. Tabelle 5.7 zeigt dazu zwei weitere Datentabellen, einen Grundobjekt- 
typ Lieferant und eine Tabelle Lief erantArtikel. Nur in ihr können wir 
den gewünschten lieferantenspezifischen Preis abbilden. Dieser Preis ist Eigenschaft 
einer Verbindung zwischen den Grundobjekttypen Lieferant und Artikel. 
Die Tabelle Lief erantArtikel könnte außer dem Preis auch noch weitere Ei- 
genschaften in Form von Attributen haben, etwa Warenklasse = {Marken, 
NoName} und andere. 



Tabelle 5.6. Beispiele gleichartiger Artikel 

Artikel 

ArtNr Bezeichnung Marke Preis Dimension 



611 


Toaster 


Row 


48,50 


St 


920 


Toaster 


- 


29,95 


St 


063 


Toaster 


Elan 


36,00 


St 



Tabelle 5.7. Grundobjekttyp Lieferant und lieferantenspezifischer Artikelpreis 



Lieferant 

Liefl^r Name Stadt LiefKls 


LieferantArtikel 

LiefNr ArtNr Preis 


12 Rowa Wuppertal B 

16 Metro Alzey A 

47 EHG Bielefeld A 


12 611 45,20 

47 611 47,00 

16 920 19,90 



Der Grundobjekttyp Lieferant wurde hier recht einfach abgebildet. Er hat ein At- 
tribut Lief erKlasse, das die Zuverlässigkeit des Lieferanten durch Kennzeich- 
nungen wie A , B , C ausdrückt, wobei A die beste Wertung sein soll. Die Verbin- 
dungstabelle zwischen zwei Grundobjekttypen trägt hier die Daten, auf deren Basis 
ein Einkäufer zu entscheiden hat. Er kann zwischen dem billigeren, aber weniger 
zuverlässigen Lieferanten (Lief Kl s = B) und dem teureren, aber verlässlicheren 
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wählen. Trotz des lieferantenspezifischen Artikelpreises bleiht der Preis als Attribut 
in der weiter oben besprochenen Bedeutung als Eigenschaft des Artikels bestehen. 

Nach der sehr ausführlichen Diskussion von Teil können die verbleibenden 
Grunddaten II kürzer abgehandelt werden, weil sie weniger komplex sind. 

Weitere operative Grunddaten 

Die Grundobjekttypen Kunde und Mitarbeiter sind, generalisiert betrachtet, 
Personen, der Mitarbeiter eine natürliche, der Kunde nicht selten eine juristische. 
Wir werden jedoch auf derartige Hierarchien nicht eingehen, da sich außer Name und 
Adresse keine generalisierten Attribute ergeben. Daher genügt für unsere Zwecke 
die folgende Auflistung: 

Kunde [KundenNr, Name, Adresse, BonitaetsKls ) 

Mitarbeiter {PersonalNr, Name, Vorname, GeburtsDat, 

GebName, KindAnz, Adresse, GehaltsGrp, EintrittsDat) 

Dies gilt, so lange die Grundobjekttypen aus Sicht des Unternehmens einfach gese- 
hen werden. Muss aber z.B. ein Betriebsteil des Kunden beliefert und mit der Zentra- 
le abgerechnet werden, oder muss das Kindergeld für den Staat ausgezahlt werden, 
für das man die Geburtsdaten der Kinder benötigt, bekommt man wieder mehrstufi- 
ge Strukturen. Sie lassen sich jedoch mit den bis jetzt bekannten Mitteln formulieren 
(Beispiele Anlage und Teil). Die sehr differenzierten Kundenstrukturen von Han- 
delsunternehmen, die von Industrieunternehmen beliefert werden, können bei Becker 
& Schütte (2004) nachgelesen werden. 

Ein einfacher Grundobjekttyp von großer praktischer Bedeutung ist der Kon- 
tenplan. Er umfasst neben der jeweiligen Kontenbezeichnung nur noch die bei- 
den Attribute BilanzTyp und ErfolgsTyp mit den Wertebereichen {aktiv, 
passiv, Wechsel} für Aktiv-, Passiv- und Wechselkonten und {erfolg, 
bestand} für Erfolgs- und Bestandskonten. Der Grundobjekttyp ist definiert als: 

Kontenplan {KontoNr , Bezeichnung, BilanzTyp, ErfolgsTyp) 

Ebenso wäre als Beispiel für eine Reihe weiterer einfacher Grundobjekttypen die 
Organisationseinheit zu nennen. Sie hat ebenfalls nur drei Attribute, von denen aber 
das dritte eine große strukturelle Bedeutung hat: 

OrgEinheit (OrgEinhNr, Bezeichnung, Kosten stelle) 

Die Kostenstelle ist eine typische Kategorie (s. Seite 70) die als Aufzählungstyp 
abgebildet sein kann. Das Beispiel soll vor allem vermitteln, dass es ein schwerer 
betriebswirtschaftlicher Strukturfehler ist, Kostenstellen und Organisationseinhei- 
ten gleich zu setzen. Erstere ist eine Stelle, der Kosten zugeordnet werden, letztere 
ein Verantwortungsbereich. Bei Umstrukturierungen zerstört man durch eine solche 
Gleichsetzung die Integrität der Grundrechnung. Allgemeiner: 

Jedes Attribut darf nur genau ein semantisches Eaktum abbilden, niemals 
mehrere. 
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Das in Tabelle 5.2 mit aufgezählte Lager nimmt eine Sonderstellung ein. In vie- 
len Unternehmen, die auch Läger an mehreren Standorten haben, genügt eine Num- 
mer oder ein Kurzcode, um ein Lager zu kennzeichnen. Dann ist das betriehliche 
Objekt Lager nur als Kategorie abgebildet, die im nächsten Abschnitt mit einem 
Lager-Beispiel behandelt wird. 

Wenn man jedoch weitere Eigenschaften über dieses Objekt der Realwelt daten- 
mäßig festhalten möchte, muss ein Lager als Grundobjekttyp II behandelt werden mit 
Eigenschaften in Eorm folgender Attribute: Grundfläche, Höhe, Zahl der Stellplätze, 
Gebäude, Stockwerk usw. Den Aufwand zu Modellierung und Pflege dieser Daten 
wird man aber nur dann betreiben, wenn dispositive Anwendungssysteme benötigt 
werden, die diese originären Daten für ihre Berechnungen voraussetzen. 

Die dritte Gruppe von Grunddaten ist sehr einfach strukturiert. 

5.4.3 Kategorien (Grunddaten III) 

Zu den Grunddaten zählen auch die Kategorien, im Praktikerjargon Schlüssel ge- 
nannt. Sie sind einfach strukturiert, da sie maximal als zweispaltige Tabellen existie- 
ren, aber anders zu behandeln sind als etwa die zweispaltige Tabelle Frei sGruppe. 
Logisch sind Kategorien Attribute vom Typ enum (Aufzählung). Als Tabellen wer- 
den sie nur auf Grund der einfacheren Pflegbarkeit als sogenannte Schlüsseltabellen 
ln Datenbanken gespeichert, also aus technischen Gründen. Da die Elemente von 
Aufzählungstypen oft als leicht handhabbare Kürzel definiert werden, enthalten sol- 
che Schlüsseltabellen genau zwei Spalten, und zwar eine Langform oder Erläute- 
rung und den dazu passenden Kurzcode als Zeichenkette oder ganze Zahl. Tabelle 
5.8 zeigt zwei Beispiele für Werk und Lager. Von solchen Kategorien gibt es in 
fast jedem Unternehmen einige Hundert. Sie spielen in betrieblichen Daten eine sehr 
große Rolle, ganz besonders auch für das Controlling, da dies die Merkmale sind, 
nach denen man Daten klassifiziert und verdichtet. Sie bedürfen eines besonders 
sorgfältigen Entwurfs und entsprechender Pflege. 



Tabelle 5.8. Zwei Schlüsseltabellen 



Werk 

WerkKnz Bezeichnung 


Lager 

LagerNr Name 


ALT Altenstadt 
AUG Augsburg 
HÖR Horstmar 
RHE Rheine 
SOG Schongau 


701 Zentrallager Rheine 

640 Außenlager Horstmar 

122 Lager Altenstadt 

123 Regionallager Peiting 



Weitere Beispiele für Kategorien aus verschiedenen Bereichen zeigt Tabelle 5.9, 
wobei die Terminologie an das Softwaresystem SAP R/3 ® angelehnt ist, das im 
Bereich Daten auch betriebswirtschaftliche Begriffe allgemein gültig geprägt hat. 
Wenn ein Unternehmen Standardsoftware installiert, importiert es zwangsläufig eine 
Vielzahl neuer oder geänderter Kategorien, die dann die alten Begriffe verdrängen. 
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Tabelle 5.9. Beipiele für Kategorien betrieblicher Daten 



Firmenstruktur Rechnungswesen Materialwirtschaft Vertrieb 



Mandant 


Kostenart 


Material art 


Sparte 


Werk 


Kostenstelle 


Produktgruppe 


Gebiet 


Buchungskreis 


Belegart 


Saison 


Bezirk 


Geschäftsbereich 


Buchungsschlüssel Materialklasse 


Kundengruppe 


Vertriebsbereich 




Bewegungsart 


Versandart 


Kostenrechnungskreis 






Marke 



Wir wollen Kategorien nur als Aufzählungstypen notieren, also nicht als Ob- 
jekttypen. Dies vereinfacht die Modellierung, ohne Realitätsaspekte unzulässig zu 
verkürzen. Wir notieren die Kategorien mit allgemein verständlichen Abkürzungen 
oder auf Basis einmal erklärter Kürzel, wie das in Tabelle 3.11 gezeigt wurde. Für 
das Beispiel aus Tabelle 5.8 schreiben wir 

Werk = {ALT, AUG, HÖR, RHE, SOG}, 

da die Abkürzungen im betroffenen Unternehmen bekannt sind. Sie gehören neben 
der in Abschnitt 3.4.3 besprochenen Namengebung zur Sprachkultur einer Orga- 
nisation, die entweder relativ unsystematisch „wächst“ oder systematisch gepflegt 
wird. Eine auf konsequenter Namengebung und damit Begriffsbildung beruhende 
Sprachkultur ist Voraussetzung für ein erfolgreiches Wissensmanagement in einem 
Unternehmen (s. Abschnitt 4.3). 

In Kapitel 6 werden wir auf die weit verbreiteten klassiflzierenden Schlüssel ein- 
gehen, die es aus Gründen der früher vorherrschenden manuellen Datenverarbeitung 
noch fast überall gibt. Sie sind nichts Anderes als in Zeichenketten zusammenge- 
zogene Kategorien, die sich mit heutigen datentechnischen Mitteln fast immer pro- 
blemlos handhaben lassen, ohne Ihre höchst problematischen Eigenschaften zu über- 
nehmen. Hierzu zählen auch hierarchische Kategorien wie z.B. die deutschen Post- 
leitzahlen oder die Nummern der Standard-Kontenrahmen. Die Lösung kann aber 
erst mit den formalen Mitteln des Folgekapitels vermittelt werden. 

Zusammenfassung Abschnitt 5.4 

1 . Allgemeine Strukturen 

o Betriebliche Objekte werden als zusammengesetzte Datentypen {Objektty- 
pen) beschrieben, deren Attribute diejenigen Eigenschaften der Objekte sind, 
die wir als Daten aufzeichnen wollen. 

o Hinter der Zuordnung von Eigenschaften zu Objekttypen können Entschei- 
dungen des Unternehmens oder der Umwelt stehen (Bsp. Preis). 

o Grundobjekttypen stehen für Objekte bzw. Subjekte der realen oder gedach- 
ten Welt, die statisch, also zeitlos betrachtet werden. 

o Die Attribute müssen an Hand ihrer Wertebereiche sorgfältig daraufhin ge- 
prüft werden, ob sie Eigenschaft nur des Objekttyps sind und nicht von etwas 
Anderem. 
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o Wollen wir zeitliche oder objektbezogene Strukturen abbilden, müssen wir 
komplexere Datentypen bilden als nur einfache Tabellen (Bsp. Teil, An - 
läge). 

o Wenn Grundobjekttypen Beziehungen zueinander haben sollen, müssen zu- 
sätzliche Objekttypen entworfen werden. Dies gilt bei Verbindungen mit 
sich selbst (Bsp. Stückliste), zwischen verschiedenen Grundobjektty- 
pen (Bsp. Lief erantArtikel) und bei Beziehungen zu einem virtuellen 
Grundobjekttyp Zeit (Bsp. AnlagenZustand). 

2. Anwendungsspezifisches 

o Die für den Routinebetrieb besonders wichtigen Grundobjekttypen sind 
Produkt, Kunde, Lieferant und Mitarbeiter. Sie sind komplex 
strukturiert, können aber von Anfängern zunächst als einfache Tabellen (oh- 
ne Hierarchien und Rollen) modelliert werden, 
o Die Grunddaten zum Produkt werden im Detail sehr komplex, weil Hierar- 
chien oft Rollen darstellen. 

o Durchgängig abstrahierende Produktdaten (Teil) bestimmen die Möglich- 
keiten wichtiger Dispositionsrechnungen wie der Bedarfsrechnung, 
o Das Erfassen von Grunddaten verursacht Kosten. Deshalb wird man nur die- 
jenigen Grundobjekte mit denjenigen Attributen pflegen, die für operative, 
dispositive und informative Zwecke benötigt werden (Bsp. Lager), 
o Datennamen sind Begriffe. Eine systematische Namengebung fördert die 
Sprachkultur und damit das Wissensmanagement eines Unternehmens. 

3. Spezielle Strukturen 

o Bel Rollenhierarchien muss geprüft werden, welche Attribute Eigenschaf- 
ten welcher Rollen sind. Gegebenenfalls müssen semantische Eestlegungen 
getroffen und schriftlich hxiert werden. Von diesen Eestlegungen hängt die 
Korrektheit von Programmen ab, die abgeleitete Daten erzeugen, 
o Es kann sich als notwendig erweisen, Attribute bezüglich ihrer Werte zu stan- 
dardisieren und als separate, mit den ursprünglichen Objekttypen verknüpfte 
Tabellen zu modellieren (Bsp. PreisGruppe). 
o Eine sehr große Gruppe der Grunddaten ist einfach strukturiert. Dies sind die 
Kategorien, im betrieblichen Jargon Schlüssel genannt. Sie werden nicht als 
Objekttypen, sondern als elementare Datentypen der Art enum (Aufzählung) 
modelliert. 

o Da Kategorien auch Objekte benennen, können sie zu komplexeren Grund- 
objekttypen werden, wenn man außer der Bezeichnung weitere Eigenschaf- 
ten abbilden möchte. Ein Beispiel hierfür ist der Typ Lager. 

Wir haben noch nicht geklärt, wie Grunddaten irgend etwas steuern (s. Satz 1 
von Abschnitt 5.4). Dies geschieht im nächsten Abschnitt, in dem unter anderem das 
Zusammenspiel zwischen Grund- und Vorgangsdaten gezeigt wird. 
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5.5 Vorgangsdaten 

Die Vorgangsdaten sind nicht zeitlos wie die Grunddaten, im Gegenteil, sie sind im- 
mer auf den Zeitpunkt bezogen, an dem der Vorgang stattgefunden hat, enthalten also 
immer ein Attribut VorgangsDatum. Auf diese Weise protokollieren Vorgangsda- 
ten betriebliche Prozesse. Auf Grund der Anforderungen des Externen Rechnungs- 
wesens gibt es aufzeichnungspflichtige Vorgänge. Die übrigen sind nicht aufzeich- 
nungspflichtig und werden geführt, um Planungs-, Steuerungs- und Kontrollmög- 
lichkeiten zu erhalten. Auch die von Ferstl und Sinz übernommene Abb. 2.5, Seite 
15 (Lenkungs- und Leistungsflüsse) bezeichnet alle Kanten des Graphen mit den 
Namen von Vorgangsobjekttypen. 

5.5.1 Aufzeichnungspflichtige Vorgänge 

Vorgangsdaten sind die originäre „Datenspur“, die alle wichtigen „Geschäftsvorfäl- 
le“ hinterlassen. Dies tun sie teils auf der Basis gesetzlicher Vorgaben (§ 238 und 
§ 239 HGB) und teilweise auf Grund betrieblicher Erfordernisse, die das Controlling 
definiert. § 239(4) HGB regelt die. Belegpflicht, der jeder Kaufmann unterliegt. Sie 
ist zu erfüllen durch Originalbelege in Papierform oder fälschungssicher gespeicher- 
te Belegdaten (§ 257(1) Nr.4). Die „Belegdaten“ sind unsere Vorgangsdaten, von 
denen die wichtigsten in den Geschäftsprozessen Beschaffung, Vertrieb (bzw. Auf- 
tragsabwicklung, vgl. Abb. 2.4) und Kundendienst entstehen. 



Tabelle 5.10. Aufzeichnungspflichtige Vorgangsdaten des Routinebetriehs 

Vorgang Datentyp 

Forderung Rechnung (Kunde) 

Zahlung Entgelt (Mitarbeiter) 

Rechnung (Lieferant) bzw. deren Begleichung 
Zahlungsverpflichtung Bestellung bzw. Wareneingang 

Bestands Veränderung Vorräte Lagerbewegung (Warenein- und -ausgang) 



Alle mit tatsächlichen oder absehbaren Vermögensveränderungen verbundenen 
Vorgänge sind nach § 240 HGB aufzeichnungspflichtig. Die im Routinehetrieb wich- 
tigsten sind in Tabelle 5.10 grob benannt, andere - wie z.B. Tilgungen von Krediten 
oder Abschreibungen - rechnen wir hier nicht dazu. 

Über die Prozesse sind die in Tabelle 5.10 gezeigten Vorgangsdaten stark mit- 
einander vernetzt. Dies lässt sich an der Lagerbestandsführung zeigen. Aufzeich- 
nungspflichtig sind nur Zu- und Abgänge aus dem Unternehmen (s. Abb. 1.1). Indi- 
rekt müssen jedoch auch alle internen Lagerbewegungen aufgezeichnet werden: Da 
jede Rechnung aufzeichnungspflichtig ist, gebietet die Belegpflicht, dass auch alle 
Vorgänge, die zu ihr geführt haben, nachvollziehbar sind. Dies sind der Auftrag, die 
Abgangsbuchungen vom Lager und der Lieferschein. Um das deutlich zu machen, 
wird der Vorgang Lagerahgang mit seinen umgebenden oder auslösenden Vorgängen 
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Ausschnitt Prozess Vertrieb 




Abb. 5.6. Ausschnitt aus Abb. 2.4 (Teilprozesse Absatz) 




Abb. 5.7. Funktion Versand verfeinert (Lagerabgang) 
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gezeigt. Abb. 5.6 ist ein Ausschnitt aus Abb. 2.4 (Teilprozesse Absatz), weshalb das 
Prozessende-Symbol fehlt. 

Der freigegebene Auftrag ist Auslöser für den Versand. Dieser ist in Abb. 5.7 ver- 
feinert modelliert. Man sieht, dass eine Entscheidung darzustellen ist, die in vielen 
Betrieben automatisiert durch Programme zur Versandabwicklung gefällt wird. Im- 
plizit kann man sie schon aus den zwei Ausgängen der Aktivität Versand in Abb. 5.6 
ablesen, in denen Nachrichten an mehrere Funktionen übermittelt werden. Dabei ist 
es kein Zufall, dass in Abb. 5.7 ein speziell gekennzeichneter, abgeleiteter Objekttyp 
/Bestand auftaucht, der mit einer anderen Art von Assoziation erzeugt wird. Der 
geschlossene Pfeil drückt in UML eine synchrone Kommunikation aus (s. Kapitel 4), 
gegenüber den sonst in den Prozessdarstellungen ausreichenden asynchronen Über- 
gängen. Technisch ist die Aktualisierung sogar zwingend eine Datenbanktransaktion 
(s. Abschnitt 2.3.3). 

Abb. 5.8 zeigt dies auch als Datenstruktur, in der jede Lagerbewegung den (bi- 
lanzpflichtigen) Bestand ändert. Beim Buchen (originärer) Vorgangsdaten werden 
(abgeleitete) Bestandsdaten erzeugt, zu denen die Ableitungsvorschrift als Integri- 
tätsbedingung angegeben werden muss. Abgeleitete Beziehungen {Assoziationen) 
oder Daten werden nach UML mit einem Slash (’/’) gekennzeichnet. Eine solche 
Assoziation ist zwingend mit einer Berechnungsvorschrift zu versehen. 




/Bestand {LagerNr, ArtikelNr, Mindestbestand, Menge) 

L 

Bestand.Menge^ = Bestand.Menge^ j -i- Bewegung.Mengej 

Bewegung {LagerNr, ArtikelNr, Datum, Zeit, Menge) 

t = Zeitpunkt 



Abb. 5.8. Die Erzeugung abgeleiteter Daten über Operationen 



Die Buchung spielt eine ähnliche Rolle wie die (Lager-)Bewegung. Sie ist der 
einzige (originäre) Vorgangsdatentyp des Rechnungswesens, obwohl die abgeleite- 
ten Typen / Konto und /Bilanz viel eher ins Blickfeld treten. Jeder Buchungssatz 
der doppelten Buchführung (Doppik) ist ein Vorgangsobjekt aus im Grundsatz zwei 
Buchungen (bei gemischten Buchungssätzen kann eine davon in mehrere Elemente 
zerfallen), die sowohl in „Büchern“ aus Papier als auch in IT-Speichern zwingend 
als Transaktion ablaufen müssen: 

Es wird entweder vollständig oder gar nicht gebucht. 

Leicht formalisiert, lautet das Schema eines Buchungssatzes (Wielenberg, 2005, Ab- 
schn. 3.3): 

Soll-Konto I Betrag | an | Haben-Konto | Betrag 
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Da der Betrag beim Standard-Buchungssatz (nicht gemischt) immer gleich sein 
muss, ist er im folgenden Datentyp nur einmal enthalten, ergänzt um andere wichtige 
Attribute. 

Buchung (BuchungsNr, DatZeit, Soll . KontoNr , 

Haben. KontoNr, Betrag, Text, BelegNr) 

Die BelegNr verweist auf den der Buchung zu Grunde liegenden, aufzeich- 
nungspflichtigen Beleg, etwa einen Lieferschein (Verkauf), eine Lieferantenrech- 
nung (Einkauf) oder einen Erstattungsbeleg (Reisekosten eines Mitarbeiters). Die 
Buchung besteht im einfachen Fall aus zwei Positionen, die den Betrag auf der je- 
weils richtigen Seite (Soll / Haben) in das angegebene Konto buchen. Was die „richti- 
ge Seite“ ist, wissen Buchhalter bereits seit etwa 400 Jahren, sie handeln auch richtig 
(s. Abschnitt 4.3, Wissen). Trotz der auch heute noch gegebenen hohen Verlässlich- 
keit von Buchhaltern ist dieses Wissen jedoch längst in Programme eingeflossen, 
so dass die beiden Positionen der Buchung in jedem Standard-Buchhaltungssystem 
automatisch richtig gebucht werden, wenn ein menschlicher Akteur den Buchungs- 
satz am Bildschirm richtig eingegeben hat. Gebucht werden dabei die folgenden, im 
Standardfall zwei Positionen in einer Datenbanktransaktion: 

BuchungsPos {BuchungsNr, KontoNr, Betrag) 

Dabei sind Soll positive und Haben negative Beträge. Die 0 kann nicht Vorkom- 
men, weil es nichts zu buchen gäbe. Entsprechend den Regeln der Doppik (Wielen- 
berg, 2005) werden Zugänge auf Aktivkonten im Soll mit Gegenbuchung Im Haben 
eines anderen Kontos und Abgänge auf Passivkonten genau umgekehrt gebucht. Bei 
gemischten Konten hängt die „Seite“ des Kontos (Soll oder Haben) vom Saldo ab. 
Dies bedeutet, dass die eigentlichen Konten der Buchhaltung abgeleitete Daten sind, 
die wir aber wegen des Kontextes, wie beim Lager, zusammen mit den Vorgängen 
betrachten müssen. Dies ergibt: 

/Konto {KontoNr, BuchungsNr, Text, DatZeit, Betrag) 

Ein Attribut für Soll- und Habenbuchungen ist nicht erforderlich, da die Integri- 
tätsbedingung 

Betragso;/ > 0; Betragnaben < 0 

bestimmt, auf welcher Seite in ein Konto gebucht wird. Dabei werden nur die Vor- 
gänge des Typs Buchung (= ein Buchungssatz) dauerhaft gespeichert, da nur über 
sie die BelegNr nachvollziehbar bleibt. Die Buchungspositionen werden 
maschinell erzeugt und müssen nicht gespeichert werden. Nach Datum sortiert aus- 
gegeben, bilden die Buchungssätze das sog. Journal, das ist die zeitliche Reihenfolge 
aller Buchungen. Es stellt eine wichtige Informationssquelle für Buchprüfer dar. 

In realen Fällen kann ein Buchungssatz auch aufgesplittet sein, z.B. wenn Rech- 
nungsnetto, Skonto und Umsatzsteuer Bestandteile eines vom Kunden überwiesenen 
Rechnungsbetrages sind. Die drei Bestandteile werden auf verschiedenen Zielkonten 
verbucht. Dies ändert jedoch nichts am vorab erläuterten Prinzip eines Vorgangs mit 
zwei Positionen. Lediglich die Transaktion wird komplizierter. 
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Wir wollen jetzt die Vorgangsdaten der Auftragsabwicklung genauer betrachten, 
die sowohl aufzeichnungspflichtige als auch nicht verpflichtende Objekttypen mit 
großen Gemeinsamkeiten enthalten. 

5.5.2 Vorgangsdaten als Prozessdokumentation 

Über Ähnlichkeiten zwischen Auftrag, Lieferschein und Rechnung wurde bereits 
gesprochen. Dies soll jetzt hinterfragt und verallgemeinert werden. Abb. 5.9 zeigt 
zunächst als einfache Skizze, welche Objekttypen den Prozess Verkaufsabwicklung 
dokumentieren. 



1 Anfrage 




vl— 

\ Angebot 




\1 Auftrag 


\~l Auftr.Bestät. 


\ Lieferschein 


ZeitX^ 


lechnung 


Mahnung 



Abb. 5.9. Rollen der Datentypen der Verkaufsabwicklung 



Bei näherem Hinsehen auf die Attribut-Ehene sieht man, dass sich die Daten- 
typen, die während des Prozesses entstehen, sehr ähnlich sind. Es gibt lediglich 
Verweise auf die jeweiligen Vorgänger, also Auftrag auf Angebot, Rechnung 
auf Auftrag usw. Dies legt den Gedanken nahe, die Objekttypen zu einem Ver- 
kauf sbe leg zu generalisieren und wie bei Teil die konkreten Belege als Rolle 
zu verstehen. 

Angebot {AngebotsNr, Datum, Text, KundenNr, Wert) 

Auftrag (AuftrNr, Datum, AngebotsNr , Text, KundenNr, Wert) 
AuftrBestät (AuftrBestNr, Datum, AuftrNr, Text, KundenNr, Wert) 
Lieferschein (LieferschNr, Datum, AuftrNr, Text, KundenNr, Anzahl) 
Rechnung (RechnungsNr , Datum, AuftrNr, Text, KundenNr, Wert) 
Mahnung {MahnungsNr, Datum, RechnungsNr, Text, KundenNr, Wert) 

Diese Rollen zeigt Abb. 5.10 in der Notation UML. Es sind die Rollen, die ein 
Auftrag in der Abwicklung einnehmen kann. Bis auf die Rechnung sind es betrieh- 
liche Entscheidungen, welche dieser Rollen ein Unternehmen datenmäßig festhält. 
Sie nehmen mit der Individualisierung der Produktion und natürlich auch mit dem 
Wert der Produkte zu. Ein Einzelfertiger wertvoller Produkte (z.B. Werft, Bauun- 
ternehmen) wird sie alle benutzen, um bis zum Kunden und im Produktionsprozess 
ein Höchstmaß an Transparenz zu erzielen. Die Rollen müssen jedoch im konkreten 
Fall nicht alle Vorkommen. Insbesondere die ersten beiden werden sich auf Einzel- 
und Kleinserienfertiger beschränken. Wenn ein Unternehmen sich einen Nutzen von 
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einer schriftlichen Auftragsbestätigung verspricht, wird es den Aufwand zu ihrer Er- 
stellung betreiben. Wenn es am Markt auch ohne sie bestehen kann, wird es die Auf- 
tragsbestätigung weg lassen, da sie Kosten verursacht. Diese Kosten sind heute im 
Internet so niedrig geworden, dass inzwischen auch im Massengeschäft Auftrags- 
bestätigungen als E-Mall üblich werden (z.B. Amazon oder Deutsche Bahn). Das 
darf aber nicht so verstanden werden, dass das Internet für jede Art von Verkauf das 
richtige Medium ist. 

Man sieht nicht nur, dass die Eolge der Vorgänge den Prozess Verkaufsabwick- 
lung abbildet, man kann sogar den Rollen der Datentypen die Phasen einer Trans- 
aktion aus der Transaktionskostentheorie zuordnen (s. Picot, Reichwald & Wigand, 
2001). Die Phasen sind in Abb. 5.10 unterhalb der Objekttypen angegeben. 




Anbahnung | Vereinbarung | Durchführung | Kontrolle 

Abb. 5.10. Rollen des generalisierten Objekttyps Verkaufsbeleg 



Der aufmerksame Leser wird bemerkt haben, dass unsere Daten der Verkaufs- 
abwicklung unvollkommen sind. Ein Auftrag bezieht sich schließlich selbst auf dem 
Wochenmarkt auf Objekte, die man kaufen möchte, und zwar möglichst mehrere mit 
einer Transaktion. 

Um nicht alle Attribute von Auftrag, Rechnung usw. für jeden Artikel zu 
wiederholen, bildet man hierfür separate Tabellen {Positionen), die mit der jeweiligen 
Rolle verknüpft sind: 

AngebotsPos {AngebotsNr, ArtikelNr, Menge, Preis) 

AuftragsPos (AuftrNr, ArtikelNr , Menge, Preis) 

AuftrBestPos {AuftrBestNr, ArtikelNr , Menge, Preis) 

LieferscbPos {LieferschNr, ArtikelNr , Menge) 

RechnPos {RechnungsNr, ArtikelNr , Menge, Preis) 

MahnPos {Mahnung sNr , ArtikelNr, Menge, Preis) 

Man sieht, dass alle spezialisierenden Positionen mit Ausnahme des Liefer- 
scheins identische Attribute haben. Dort fehlt das Attribut Preis. Ein Lieferschein 
ist die Information, die notwendig ist, um einen Materialfluss zu begleiten. Es inter- 
essiert nur die Menge und nicht der Preis. Dieser ist Teil der Rechnung, die oft auf 
anderem Wege befördert wird. Üblich sind inzwischen in der „Versandlogistik“ auch 
Konstrukte der Art Lief erschein-und-Rechnung. 
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Die Generalisierung der Datentypen des Prozesses zu Verkaufsbeleg scheint also 
sinnvoll zu sein. Wir betrachten den Verkaufsbeleg hier nur konzeptionell und fragen 
noch nicht nach einem Datentyp dieses Namens und seiner Attribute. Dies ist erst 
notwendig, wenn wir uns genauer mit den Strukturen befassen müssen (s. Kapitel 6). 

Ein Datentyp der Verkaufsabwicklung, der noch in die Anbahnungsphase gehört, 
wurde nicht in die Generalisierung mit einbezogen, die Anfrage. An ihr kann man 
zeigen, wie Daten sich stufenweise vom unstrukturierten Text (formloser Brief) zum 
strukturierten Datentyp wandeln (s. Kapitel 9). 

Anfrage« (AnfrageNr, Datum, Text, Absender) 

Anfrage^ (AnfrageNr, Datum, Text, KundenNr) 

Anfrage« (AnfrageNr, Datum, Text, KundenNr) 

AnfragePos« (AnfrageNr, ArtikelNr, Menge) 

Fall a) tritt ein, wenn ein anonymer Nachfrager des Marktes in der Rolle Interes- 
sent auftritt. Er kann noch keine KundenNr haben. Im Fall b) ist er bereits Kunde 
oder bekannter Interessent und hat eine Kundennummer. Fall c) hat dieselbe Struktur 
wie ein Angebot, nur dass die Datenstruktur aus Sicht des Kunden gesehen wird. 

Wir können jetzt das hier Gezeigte verallgemeinern, indem wir eine generelle 
Struktur für Vorgangsdaten vorstellen. 

5.5.3 Eine Referenzstruktur für Vorgangsdaten 

Wie an den Rollen des Verkaufsbelegs gezeigt, kommen wir mit einer flachen Ta- 
bellenstruktur nicht aus. Wir benötigen für fast alle Vorgangsdaten zwei Datentypen, 
um sie in Tabellenform abbilden zu können, und zwar in einer einheitlichen Struk- 
tur. Dies wird in Abb. 5.11 am Beispiel eines Auftrags grafisch und verbal gezeigt. 
Wir sehen die Referenzstruktur Komposition (gepunkteter Rahmen), die eine Gan- 
zes - Teile - Beziehung ausdrückt, gekennzeichnet durch eine Raute als Kantenende 
beim Ganzen. Das Ganze existiert genau einmal, von den Teilen muss mindestens 
ein Exemplar existieren. Der Auftrag als Ganzes ist ein Aggregat, das sich auf einen 
Kunden bezieht, enthält aber Bezüge auf viele Artikel. 




Als Datentypen: 

Auftrag (AuftragsNr, KundenNr, EingangsDat) 



t 



AuftragsPos {AuftragsNr, ArtikelNr, Menge) 



Artikel {ArtikelNr, Bezeichn, Dimension, Preis) 



Abb. 5.11. Komplexer Objektttyp mit Verweis auf Grundobjekttypen 
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Die betrieblichen Vorgänge bestehen fast immer aus Positionen, von denen sich 
jede auf genau ein manipuliertes Objekt bezieht, hier den Artikel als kleinste Ver- 
kaufseinheit. Ein konkreter Auftrag wiederum ist genau einem Kunden zugeordnet, 
der jedoch zu verschiedenen Zeiten mehrere Aufträge erteilen kann. Dies erklärt, 
warum wir Abb. 5.10 nicht korrigieren müssen. Jedes Rechteck der Spezialisierun- 
gen ist ein komplexer Objekttyp der Art Komposition, bestehend aus zwei Tabellen, 
wie in Abb. 5.1 1 gezeigt. An dieser Stelle sei auch an die sehr ähnliche Abb. 3.1 und 
die dort gemachten Aussagen zur Verknüpfung der Tabellen über Zeiger erinnert 
(Verweis auf den Kunden). 

Die Komposition ist die Referenzstruktur zumindest für alle hier betrachteten 
Vorgänge des Routinebetriebs. Selbst ein seltener Vorgang wie die Einstellung einer 
Eührungskraft kennt mehrere Bewerber. Dem widerspricht auch nicht der degene- 
rierte Eall, in dem es nur ein Exemplar beim Teil gibt, etwa wenn ein Mitarbeiter 
scheinbar nur einen Leistungsnachweis führt. Ohne ein Teil macht das Ganze keinen 
Sinn, d.h. es kann keinen Auftrag mit 0 Auftragspositionen und keine abrechenbare 
Leistung ohne nicht wenigstens einen Nachweis derselben geben. 

An Abb. 5.11 ist auch zu sehen, welche Bedeutung Attribute von Grund- und 
Vorgangsdaten haben. Alle dauerhaften Eigenschaften sind Attribute der Grunddaten 
(Preis), nur die temporären gehören zu den Vorgangsdaten (Menge). 

5.5.4 Weitere Vorgangsdaten 

Nachdem die Vorgangsdaten Verkaufsbeleg, Buchung und Bewegung erläutert 
sind, verbleiben von den allgemein verbreiteten Routinevorgängen (s. Tabelle 5.2) 
noch die folgenden: 

Einkaufsbeleg {BestellNr, Datum, Text, LieferantNr, Wert) 
Leistung {LeistungsNr, Datum, AuftragsNr) 

Der Einkaufsbeleg ist spiegelbildlich zum Verkaufsbeleg zu sehen. Meist wird 
er einfacher sein, da keine Notwendigkeit besteht, die Organisation des Lieferanten 
so differenziert abzubilden wie die eigene. Lediglich die Artikelnummer des Liefe- 
ranten wird man angeben müssen. In der Regel genügt ein Objekttyp Bestellung, 
dessen Zustände in einem Aufzählungstyp Zustand abgebildet sind: 

Bestellung . Zustand = {angefragt, bestellt, unterwegs, 

geliefert} , 



so dass sich ergibt: 

Bestellung {BestellNr , Datum, Text, LieferantNr, Zustand, Wert) 
BestellPos {BestellNr, ArtikelNr, Lief ArtikelNr , Menge). 

Ein Einkaufsbeleg Abruf (s. Tabelle 5.2) ist datentechnisch identisch mit einer Be- 
stellung. Die juristisch wirksame, hinter dem Abruf stehende „Bestellung“ ist ein 
Rahmenvertrag. 

Die Leistung muss ausführlicher erläutert werden. Eine Leistung wird erbracht 
von einem Mitarbeiter, allerdings weist sie immer eine zusammengesetzte Struktur 
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auf. Die Struktur kann jedoch in verschiedenen Ausprägungen auftreten. Entweder 
will man die Leistungen im Zeitablauf sehen. Dann wird sich Leistung auf einen 
Kunden- oder Produktionsauftrag beziehen. Sie kann aber auch direkt auf Aufträ- 
ge bezogen werden. Dann ergibt sich eine umgekehrte Struktur der Komposition 
zwischen dem Ganzen und seinen Teilen. Wir zeigen zwei aus mehreren denkbaren 
Varianten zu Abb. 5.12. 

Leistung« {LeistungsNr, Datum, AuftragsNr) 

LeistungsPos« (LeistungsNr, PersonalNr, Dauer, Tätigkeit) 
Leistung^ {LeistungsNr, Datum, PersonalNr) 

LeistungsPoSfc (LeistungsNr, AuftragsNr, Dauer, Tätigkeit) 




verschiedener Mitarbeiter an mehreren Aufträgen 

Abb. 5.12. Zwei Varianten der Leistungserbringung 



Betriebswirtschaftlich wird hierdurch allerdings nur der einfachste Fall der Ein- 
zelfertigung gezeigt, nicht aber die Vorgänge der Serien- und Massenfertigung. Wir 
haben Leistungen mit Bezug auf einen Kunden&ufimg betrachtet und in Arbeitszeiten 
gemessen. Das entspricht der Zielsetzung dieses Buches, einfache Referenzstruktu- 
ren zu liefern, damit die Orientierung in der komplexen Realität später besser gelingt. 

Für die Produktion lassen sich nicht annähernd so allgemein gültige Strukturen 
angeben wie für den Verkauf. Um die mit Abb. 5.12 gegebenen Möglichkeiten in 
einen allgemeineren Kontext zu stellen, sei hier ein Auszug aus einem neueren Lehr- 
buch zu den prinzipiellen Vorgangsdaten industrieller Produktion gegeben, das sind 
Produktionsmengen, Werkstoffmengen, Arbeitsmengen und Maschinenlaufzeiten: 

„Die Leistungserstellung vemrsacht den Verbrauch von Produktionsfaktoren ent- 
sprechend der Produktionsfunktion 

x = f{ri,r 2 ,n) (5-1) 



mit 

X - Leistungserstellung der Periode (Menge) 
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r\ - Verbrauch an Werkstoffen (Menge) 

T 2 - Einsatz von Arbeitsstunden 

^3 - Einsatz von Maschinenstunden“ (Albach, 2001, 240) 

Die Realität sei hier nur grob angedeutet, damit der Leser wenigstens eine intuiti- 
ve Vorstellung von der großen Komplexität der Vorgangsdaten in einer repetitiven 
Produktion bekommt. 

o Die Leistung wird nicht mehr in Arbeitszeit, sondern in Produktionseinheiten ge- 
messen (Stück, Längen, Volumen), weil Standardzeiten je Einheit bekannt sind, 
o Die Leistung wird als Erfüllung von Arbeitsplänen erbracht und gegen deren 
Positionen erfasst. Arbeitspläne mit Vorgabezeiten beherrschen die Werkstattfer- 
tigung für Kleinserien. Die Vorgabezeiten sind in Rüstzeiten (Einrichten der Ma- 
schine) und Stückzeiten (Zeit pro Einheit) getrennt und müssen auch als Istzeiten 
dieser Struktur entsprechen. 

o Bei einer hoch automatisierten Großserien- und Massenfertigung fallen für die 
Produktion pro Einheit gar keine Arbeitszeiten mehr an. Zu erfassen sind die 
Leistungen für Rüstzeiten und Instandhaltung und die hier besonders wichtigen 
Laufzeiten der Maschinen (s. Gleichung 5.1). 

Zusammenfassung Abschnitt 5.5 

1. Strukturen 

o Vorgangsdaten zeichnen die Geschäftsvorfälle auf,.. 

o ..deshalb müssen sie sich auf einen Zeitpunkt beziehen (Monat, Tag, Stunde, 
ggf. sogar Sekunde), damit man gleichartige Vorgänge voneinander unter- 
scheiden kann. 

o Vorgangsdaten sind immer abhängig von Grunddaten. Das Umgekehrte gilt 
nie. 

o Alle wesentlichen Vorgänge werden in Form einer Komposition zweier eng 
verknüpfter Tabellen modelliert, 
o Abgeleitete Daten werden mit 7’ gekennzeichnet. 

2. Anwendungsspezifisches 

o Viele Vorgänge sind nach den GoB aufzeichnungspflichtig. 
o Aus den Vorgängen Lagerbewegung und Buchung (= Buchungssatz) 
werden automatisch Bestandsdaten gebildet. Dies sind /Bestand und 
/Konto. 

o Die Vorgänge der Verkaufsabwicklung reichen aus, den von ihnen aufge- 
zeichneten Geschäftsprozess zu beschreiben. Sie lassen sich als Verkaufsbe- 
leg generalisieren. 

o Die Vorgänge der Produktion sind nicht so leicht standardisierbar wie die des 
Verkaufs, der Beschaffung und der Buchhaltung. 
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5.6 Abgeleitete Daten 

Dispositive Daten sind abgeleitete Daten, die den Routinebetrieb unterstützen, wäh- 
rend aggregierte Daten für Führungszwecke stärker verdichtet sind. Die Grenze zwi- 
schen ihnen lässt sich allerdings nicht so scharf ziehen, wie dies in dem schemati- 
schen Abh. 5.1 erscheint. Sie werden jetzt beispielhaft besprochen. 

5.6.1 Dispositive Daten 

Dispositionssysteme sind diejenigen Anwendungssysteme, die dispositive Tätigkei- 
ten im Unternehmen unterstützen (s. Mertens, 2004), teilweise auch ersetzen. Diese 
Tätigkeiten zählen ebenso zum Routinebetrieb wie die bisher besprochenen. Wenn 
sie nicht vollständig automatisiert sind, laufen dispositive Tätigkeiten heute über- 
wiegend computerunterstützt ab. Die Programme erzeugen dispositive Daten für 
menschliche Entscheider, z.ß. den Nettobedarf eines Materials für einen Einkäu- 
fer. Dieser kann sich weiterer Entscheidungshilfen bedienen, etwa um eine optimale 
Bestellmenge zu ermitteln. 

Der wichtigste dispositive Datentyp jedes Unternehmens mit einem größeren Ab- 
satzvolumenen {Menge, nicht Wert!) ist ein (virtueller) Typ /Absatz, da es wichtig 
ist, etwas über die verkauften Produkte und ihre regionale und personelle Zuordnung 
(Außendienst) zu erfahren. „Virtuell“ ist der Datentyp deshalb, weil der Absatz nur 
ein Attribut des folgenden verdichteten Objekttyps ist: 

/Absatz_UmsatZa {Jahr, Monat, ArtikelNr, PersonalNr, 
/Absatz, /Umsatz) 

Die meist Vertriebs Statistik genannte, häufig noch gedruckte Liste ist eine Ver- 
dichtung aller Rechnungspositionen über alle gleichen Artikel. Sie hat bei 100 
pro Außendienstmitarbeiter und Monat verkauften Artikeln und 50 Mitarbeitern 
12* 100*50 = 60.000 Zeilen, das wären 1.200 Seiten. Es ist verständlich, wenn 
man das nicht mehr auf Papier bringen möchte, sondern eine Navigationsmöglich- 
keit über Bildschirme schaffen wird. 

In der hoch verdichteten Eorm 

/Absatz_UmsatZfe {Jahr, /Absatz, /Umsatz) 

ist das dagegen nur noch eine einzige Zeile mit drei Zahlen. Dies ist der allseits 
bekannte Jahresumsatz einer Firma. Die Größe Absatz würde überhaupt nur Sinn 
machen, wenn man homogene Produkte mit identischer Dimension hätte. Man sieht, 
dass sich viele wichtige Gruppierungen von Absatz und Umsatz erzeugen lassen. 
Dies kann nach Produkten, Außendienstmitarbeitern (für eine erfolgsabhängige Ent- 
lohnung) oder Perioden sein. Die Verdichtungsoperation ist jeweils eine simple Ad- 
dition. 

Da die Anzahl der aus den originären Daten ableitbaren Ergebnisse unüberschau- 
bar ist, geben wir in Eorm der Tabelle 5.11 nur eine Übersicht der in Lehrbüchern 
häufig genannten entscheidungsunterstützenden Verfahren, denen wir die jeweilige 
Datengrundlage zuordnen. Dies erhebt keinen Anspruch auf Vollständigkeit und ist 
auf den Leistungsbereich beschränkt. 
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Tabelle 5.11. Verfahren zur Erzeugung dispositiver Daten und ihre Datenquellen 



Funktion 


Verfahren 


Ergebnis (disp. Daten) 


Datengrundlage 


Beschaffung, 


ABC-Analyse 


Klassifik. Einkaufsteile 


Teil, Bestellung 


Lagerhaltung 


Losgröße 


Opt. Bestellmenge 


Teil, Bestellung, 
Lagerabgang 




Wiederbeschaffung 


Opt. Bestellzeitpunkt 


- wie Zeilen davor - 




Ersatzinvestition 


Opt. Ersatzzeitpunkt 


Anlage, Maschinenzeit 




Bedarfsermittlung 


Zu beschaffende oder 
zu reservierende „Teile“ 


Teil, Stueckliste 
/Bestand, Bestellung 


Produktion 


Programmplanung 


Realisierbares 

Produktionsprogramm 


Teil, Anlage 
(Kapazität) 




Durchlaufterminierg 


Liefertermin 


Teil, Arbeitsplan 




Losgröße 


Opt. Fertigungmenge 


Teil, Anlage, 
Arbeitsplan 




Verschleißteile 


Opt. Ersatzintervalle 


Anlage, Maschinenzeit 




Kalkulation 


Herstellkosten 


Teil, Stueckliste 


Absatz 


Preisfindung 


Optimaler Preis 


Rechnung bzw. Zahlung 




Nachfrage - Absatz- 
analyse 


Lieferfähigkeit 
je Produkt 


Anf rage bzw. Auf trag 




Tourenplanung 


Effizienter Außendienst 


Rechnung, Auftrag 




Gebietszuschnitt 


Opt. Vertriebsgebiete 


Auf trag 



5.6.2 Aggregierte Daten (Führungsinformation) 

Was man vielfach Führungsinformation nennt, hat in unserer Pyramide zu Beginn 
des Kapitels den Namen aggregierte Daten. Schon die kurze Diskussion von Absatz 
und Umsatz zeigt, dass die Grenze zwischen dispositiven und aggregierten Daten 
unscharf ist. So ist der Umsatz pro Monat und Jahr sicher eine wichtige Führungs- 
information, aber ebenso informativ für viele andere Mitarbeiter, die dispositiv tätig 
sind. 

Wir wollen in dieser Einführung die Vielfalt von Führungsinformationen nicht 
näher behandeln, da viele auch intuitiv vorstellbar sind. Lediglich einige Beispiele 
sollen die Vorstellungskraft etwas anregen: 

o Absatz, Umsatz, Deckungsbeitrag je Artikel und Produktgruppe; nach Regionen, 

Außendienstmitarbeitern oder im Zeitablauf, 
o Herstellkosten je Artikel und Produktgruppe (Mittelwerte, wenn sinnvoll) 
o Distributionskosten je Region 
o u.v.a.m. 

Wichtig bleibt jedoch, die Grundbotschaft der Pyramide Abb. 5.1 im Auge zu behal- 
ten. Nicht die „Schönheit“ der Repräsentation der Führungsinformation zählt, son- 
dern die Stimmigkeit der Daten mit der operativen Basis. Selbstverständlich benutzt 
man heute Präsentationsgrafiken für die Darstellung von Führungsdaten. Diese müs- 
sen aber per automatischem Transfer auf PC oder Notebook gelangt sein und nicht 
durch Abtippen von Listen des operativen Rechners. Nur so kann die Konsistenz der 
Pyramide gewährleistet werden. 
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Zusammenfassung Abschnitt 5.6 

o Für den Routinebetrieb sind von den abgeleiteten Daten die dispositiven 
besonders wichtig. 

o Sie werden heute meist durch Programme ermittelt, deren Datenbasis 
die Bestands- und Vorgangsdaten sind. 

o Aus den Vorgängen Auftrag und Rechnung werden die besonders 
wichtigen „Vertriebsstatistiken“ gewonnen. 

o Die Datengrundlage vieler Optimierungsrechnungen sind einige Grund- 
daten und die Vorgangsdaten. 

o Führungsinformationen, auch in grafischer Aufbereitung, können nur 
korrekt sein, wenn sie auf originären oder dispositiven Daten aufbauen. 



5.7 Wiederholung 

• Grund-, Vorgangs- und einige Plandaten sind als originäre Daten eine wichtige 
betriebliche Ressource. 

• Grunddaten sind zeitlos, Vorgangsdaten Zeitpunkt-bezogen, informative Daten 
(dispositive und aggregierte) meistens Zeitraum-bezogen. 

• Die operativen Grunddaten sind komplex, insbesondere der Grundobjekttyp 
Teil. 

• Vorgangsdaten haben die Referenzstruktur Komposition. 

• Kategorien als sog. Codes oder Schlüssel sind strukturell sehr einfach, aber be- 
sonders zahlreich. Sie sollten nicht als Objekttypen modelliert werden, sondern 
als elementarer Datentyp Aufzählung. 

• Dispositive Daten werden heute meist durch Anw endungs Systeme erzeugt. 

• Führungsinformation muss auf operativen und dispositiven Daten basieren, auch 
wenn mobile Rechner benutzt werden. 
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Die Struktur betrieblicher Daten 



In diesem Kapitel wird die Methodik der Datenmodellierung behandelt. Sie dient 
dazu, die betrieblichen Daten so zu strukturieren, dass sie die bereits in Kapitel 4 
aufgestellte Forderung nach Redundanzfreiheit auch erfüllen. Datenmodellierung ist 
eine sog. Semantische Modellierung (Ortner, 1985), d.h. die Bedeutung der Daten 
bestimmt auch deren Struktur. Im vorigen Kapitel hatten wir mit der Semantik den 
Inhalten Vorrang eingeräumt, mussten aber schon einige strukturelle Aussagen ma- 
chen. In diesem Kapitel ist es genau umgekehrt. Wir machen jetzt die Strukturen 
explizit und gewinnen damit Regeln zur Überprüfung der Korrektheit unserer Mo- 
delle. 



6.1 Datenmodelle 

Fachkundige Leser werden vermuten, dass in Abschnitt 3.4.4 und Kapitel 5 implizit 
das Relationenmodell (RM) zu Lasten des Entity-Relationsship-Modells (ERM) un- 
terstellt worden ist. Dieser Anschein trügt. Es wurde lediglich ein bottom-up- Ansatz 
verfolgt, der für Studierende fruchtbarer sein dürfte als der sonst verbreitete top- 
down- Ansatz mit Diagrammen. Das Problem des top-down-Ansatzes ist, dass er Ab- 
straktionen über eine Realität verlangt, die Studenten noch nicht kennen. 

Wir gehen hier auf beide Modelle ein, das RM und das ERM, die zum Einen 
eine Abfolge der Ideen haben (1970 bis 1976) und sich zum Anderen ergänzen. Es 
trifft heute nicht mehr zu, dass das RM ein DV-technisches Verfahren der Daten- 
banktechnik ist, wie es noch gelegentlich behauptet wird (Scheer, 1998; Stahlknecht 
& Hasenkamp, 2005). Die Erage, welches Modell Implementierten Datenbanken zu 
Grunde liegen sollte, ist seit Anfang der 90er Jahre faktisch entschieden, so dass es 
keine Gründe mehr gibt, die lange als Alternative diskutierten Modelle Hierarchie 
und Netz noch in die Grundausbildung hineinzuziehen. Außer für Datenbankspezia- 
listen ist das heute Technik-Geschichte. 

Anknüpfend an das vorige Kapitel fahren wir fort mit einer Objektsicht, in der 
die Objekttypen und ihre Attribute betrachtet werden. Die Objektsicht orientiert sich 




6 Die Struktur betrieblicher Daten 



in der Notation und in einigen Details am RM. Danach stellen wir eine Beziehungs- 
sicht her, in der wir nur noch die Verbindungen zwischen den Objekttypen als Gan- 
zes darstellen. Sie ist am ERM orientiert, benutzt aber als modernere und besser zu 
handhabende grafische Notation UML. 

6.1.1 Das Relationenmodell (Objektsicht) 

Bereits in Abschnitt 3.4 hatten wir die Tabelle als Objekttyp mit Attributen als 
Grundstruktur betrieblicher Daten benannt. Die Tabelle als Strukturtyp wurde von 
dem Amerikaner Codd (1970) als die flexibelste Grundlage für Datenbanksysteme 
entdeckt und Relationenmodell genannt. Das Modell hat sich als Basis relationaler 
Datenbanksysteme allgemein durchgesetzt' und bestimmt heute die Art, wie betrieb- 
liche Daten gespeichert und manipuliert werden. Es hat die genormte Abfrage- und 
Manipulationssprache SQL (Structured Query Language) hervorgebracht. 

Dem interessierten Leser sei empfohlen, die Aufsätze von Codd (1970) und Chen 
(1976) im Original zu lesen und sich nicht auf die Hunderte von Sekundär- und Ter- 
tiärdarstellungen zu verlassen, die das Thema mit bis zu 12 sog. Normalformen oder 
Sondersymbolen sehr verkomplizieren können. Codd begründet aus der Mengenleh- 
re, warum zusammengesetzte Datenstrukturen die Eorm von Tabellen haben sollten, 
deren Attribute nur aus elementaren Datentypen bestehen. Dies wurde später ers- 
te Normalform (INE) genannt; weitere brauchen wir zunächst nicht. Die gesamte 
Datenbasis vieler Unternehmen setzt sich aus solchen Tabellen zusammen, die mit- 
einander vernetzt und deren Attribute nicht redundant sind. 

Das Relationenmodell beantwortet zwei Grundfragen, die in den folgenden bei- 
den Abschnitten beantwortet werden. 

1. Wie werden Datentabellen miteinander verknüpft? 

2. Wie müssen Datentabellen gebildet werden, um Redundanzfreiheit zu erreichen? 

Ein drittes Grundanliegen von Codd war, wie man Datentabellen in neue zerlegt oder 
kleinere zu größeren zusammenfügt. Dies behandeln wir hier nicht, da es für die Da- 
tenmodellierung nicht relevant ist. Wir gehen aber auf Seite 94 und in Abschnitt 9.2 
ganz kurz auf die bei der Zerlegung entstehenden Sichten und deren konzeptionelle 
Bedeutung ein. 

Die Grundideen des Modells 

Eine Relation R ist in der Mathematik eine Teilmenge des Cartesischen Produktes 
(auch Produktmenge) von Mengen A,, also der möglichen Kombinationen der Ele- 
mente W{Ai) 



R(Ai,A2,..,A„) C W{Ai) X W{A2) X .. X W{A„) (6.1) 



* Zu nennen wären DB2 und Informix (IBM), Oracle, SQL-Server (Microsoft), ADABAS 
(Software AG) und MySQL (Open Source); mit einigen Abstrichen auch das Einzelplatz- 
System Microsoft- Access. 
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mit Wi = Wertebereich (domain) der Menge A, . Die A,- sind die Spalten einer Tabelle. 
Für die A, schreiben wir allerdings semantisch verständliche Attributnamen wie etwa 
Name oder Preis. Den Wertebereich bestimmt der Datentyp, also bei integer 
sehr viele, bei boolean genau zwei, bei enum auch eine sehr begrenzte Anzahl 
von Möglichkeiten. Zur Verdeutlichung dient Tabelle 6.1. 



Tabelle 6.1. Beispiel Cartesisches Produkt und Relation 



Cartesisches Produkt 
Al A 2 A 3 

Vorname Name Ort 


Relation 


Ines 


Meier Bielefeld 




Ines 


Meier Münster 




Ines 


Otte 


Münster 




Ines 


Otte 


Bielefeld 




August 


Meier 


Münster 




August 


Meier Bielefeld 




August 


Otte 


Bielefeld 




August 


Otte 


Münster 





Nur die gekennzeichneten Zeilen gehören zur Relation, der wir wohl den Namen 
Person gehen würden. Man sieht deutlich, dass Relationen in praktischen Fällen 
sehr viel kleinere Mengen sind als die Produktmengen. Welche Elemente zur Relati- 
on gehören, sind keine formalen, sondern semantische Entscheidungen. Eine weite- 
re semantische Entscheidung ist das Eestlegen von Datentypen für die Attribute bei 
der Konstruktion der Tabelle. Dies wird in vielen Lehrbüchern in den Bereich der 
Technik verwiesen, weil Datentypen im Zusammenhang mit Programmiersprachen 
erfunden wurden. Gerade mit Aufzählungs- und Unterbereichstypen (vgl. Abschnitt 
3.4.1) grenzen wir aber Wertebereiche der Attribute von theoretisch riesigen Domä- 
nen auf sehr kleine, betrieblich erwünschte ein. Dieser Grundgedanke des Relatio- 
nenmodells ist wichtiger als die (n+l). Normalform. Dies wurde übrigens erst durch 
Chen (1976) in seiner semantischen Tragweite herausgearbeitet, der auch in Portfüh- 
rung des Gedankens Integritätsbedingungen formuliert, also anwendungsspezihsche 
Einschränkungen von Wertebereichen. 

Die Relation ist ein Objekttyp (bei Chen Entitätstyp), der aus Elementen (7m- 
peln) besteht. Wir nennen sie hier Exemplare? Das sind die Zeilen einer Tabelle. 
Sie müssen disjunkt sein, d.h. es darf niemals zwei identische Exemplare in einer 
Relation geben. Da jedes Exemplar einzigartig ist, muss es identifizierbar sein. Dies 
geschieht durch ein besonderes Attribut oder eine Kombination mehrerer Attribute. 
Sie heißen Schlüssel der Relation (key), bzw. Primärschlüssel (primary key) weil 
wir verschiedene Arten von Schlüsseln benötigen. Der Primärschlüssel versetzt uns 
in die Lage, sicherzustellen, dass nicht etwa dasselbe Objekt mehrmals oder gar nicht 



^ Die deutsche Übersetzung des englischen instance als „Instanz“ ist falsch, hat sich aber 
leider eingebürgert. 
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behandelt wird. So kann gewährleistet werden, dass ein Mitarbeiter am Monatsende 
nicht versehentlich zwei Gehälter bekommt oder keines. 

Wir betrachten im Folgenden ein Beispiel, und zwar einen Grundobjekttyp 
Mitarbeiter. Ob für eine Karteikarte oder einen Computer, wir würden formu- 
lieren, wie Tabelle 6.2 es zeigt. 



Tabelle 6.2. Ein Grundobjekttyp Mitarbeiter 



Objekttyp 


Attribute | 


Mitarbeiter 


(Name, 


Vorname, 


Titel, 


GeburtDat, 


Geschlecht, 


Gehalt) 































Die Attribute sind die Spaltenüberschriften der Datentabelle, die Werte werden 
ln Zeilen eingetragen (s. auch Tabelle 3.7). Ganze Spalten bilden die Wertemenge 
eines Attributs, ganze Zeilen ein Exemplar, hier also ein Mitarbeiter je Zeile. Jede 
Zeile einer Tabelle muss eindeutig durch ein oder mehrere Attribute ansprechbar 
sein, den Primärschlüssel. Doch wie finden wir für unser Beispiel einen geeigneten 
Primärschlüssel? 

Zunächst liegen Name und Vorname als Schlüsselkandidaten auf der Hand. Damit 
identifizieren wir im täglichen Leben ebenfalls eine Person, ln einem Handwerks- 
betrieb mit maximal 15 Mitarbeitern könnte das ausreichen, aber schon bei Unter- 
nehmen mit 200 Mitarbeitern wird das schwierig. Was tun, wenn wir eine neue Mit- 
arbeiterin Tnes Meier’ einstehen wollen, aber schon eine gleichen Namens haben? 

Also nehmen wir das Geburtsdatum als weiteren Schlüsselkandidaten mit hin- 
zu. Jetzt bilden drei Attribute den Primärschlüssel, um Jedes Exemplar eindeutig zu 
identifizieren. Doch auch diese Lösung versagt bei Unternehmen wie der Deutschen 
Bahn oder General Motors mit über 200.000 Mitarbeitern. Dort kann auch mit drei 
Attributen keine Eindeutigkeit hergesteht werden. 

Neben dem Problem der Eindeutigkeit sind zusammengesetzte Schlüssel schwer- 
fällig in der Handhabung. Man bildet deshalb künstliche Attribute, die als Primär- 
schlüssel dienen und immer^ eindeutig gemacht werden können, meist sog. Num- 
mern. Diese künstlichen Schlüssel heiütn Alternativschlüssel (alternate key). Zwar 
Ist der am häufigsten hierfür verwendete Datentyp integer - wir kennen ihn als 
KundenNr, ArtikelNr, RechnungsNr längst im Alltag - aber zwingend ist das nicht. 
Ein Schlüssel kann einen beliebigen, abzählbaren Typ haben. So wären Alterna- 
tivschlüssel bei Kategorien (vgl. Abschnitt 5.4.3) unsinnig, weil es ja per Definition 
eine abzählbare, überschaubare Zahl von Eällen gibt. Wir halten als Regel fest: 

Alle als selbständige Objekte handhabbare Datentypen erhalten 
als Primärschlüssel einen künstlichen Schlüssel. 

^ Der Typ integer bietet auf heutigen Computern 2^^ ~ 4 Milliarden unterschiedliche 
Primärschlüssel. Das reicht für praktische Eälle aus. 
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Zu diesen Objekttypen zählen die Grunddaten I und II, nicht aber III, sowie die 
Vorgangsobjekttypen, nicht aber deren abhängige Positionen. Wir zeigen jetzt einen 
dergestalt erweiterten Grundobjekttyp (s. auch Abb. 5.12, Seite 81), bei dem wir den 
Primärschlüssel durch Unterstreichung und als Schlüssel mit ’#’ kennzeichnen: 

Mitarbeiter ( PersonalNr# , Name, Vorname, Titel, Geschlecht, 
GeburtsDat, Gehalt) 

Damit wären Primärschlüssel zur Identifikation von Objekten bzw. Tupeln einge- 
führt. Es bleibt die Verknüpfung von Tabellen, die sich aus dem Primärschlüssel auf 
fast natürliche Weise ergibt. Sie erfolgt mit Fremdschlüsseln (foreign key), die als 
Attribute in abhängige Tabellen eingefügt werden. Dies sind die Zeiger, von denen 
in den Abschnitten 3.4.4 und 5.5.3 schon gesprochen wurde. Hierzu ein Beispiel, bei 
dem wir alle Schlüssel als Primär- oder Fremdschlüssel kennzeichnen. Wir greifen 
auf das Beispiel in Abb. 5.12b) Seite 81 zurück und erhalten: 

Leistung ( LeistungsNr# , Datum, PersonalNr#) 

LeistungsPos (LeistungsNr#, AuftragsNr#, vonZeit, Dauer, 
Tätigkeit) 

Das Beispiel beantwortet alle in unserem Kontext relevanten Strukturfragen des 
Relationenmodells : 

1. Schlüssel 

o Der Grundobjekttyp (Mitarbeiter) und der Vorgangsobjekttyp (Leis - 
tung) haben künstliche Primärschlüssel. Schlüsselkandidaten von Leis- 
tung wären Datum und PersonalNr#. 
o Der Vorgangsobjekttyp - er ist abhängig - wird über einen Fremdschlüssel 
mit einem Grundobjekttyp verknüpft (PersonalNr#). 
o Die Teilschlüssel eines zusammengesetzten Primärschlüssels (Leistungs- 
Pos) sind immer auch Fremdschlüssel. 

2. Verweise 

o Ein Vorgangsobjekttyp ist auch mit künstlichem Schlüssel zeitabhängig, 
denn ein anderes Datum bei sonst identischen Attributwerten verlangt einen 
neuen Primärschlüssel. 

o Vorgänge verweisen auf den virtuellen Objekttyp Zeit. Wir verzichten bei 
Datum und anderen Zeit-Attributen, z.B. UhrZei t, auf die Kennzeichnung 
als Schlüssel. Dies vereinfacht die Modelle“^ in der Beziehungssicht, da we- 
sentlich weniger Entitätstypen entstehen, 
o Der Zeitbezug muss so genau sein, dass zwei reale Vorgänge voneinander 
unterschieden werden können. Dies ist hier der Fall, so dass Leistungs - 
Pos den Verweis auf die Zeit in Leistung (Datum) verfeinern muss, 
o LeistungsPos ist mit einem anderen Objekttyp verknüpft, hier einem 
Vorgangsobjekttyp. Die „nicht selbständig handhabbare“ (s. oben) Tabelle 



^ In der schon erwähnten Analyse einer betrieblichen Datenbasis (Spitta, 1996) waren 15% 
aller Attribute Verweise auf Zeit. 
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LeistungsPos muss einen zusammengesetzten Primärschlüssel haben, 
damit die Verknüpfungen sichtbar sind. 

o Wenn man komplexe Modelle erstellen muss, kann es notwendig sein, hier- 
für em&a Alternativschlüssel zu vergeben. Das ergibt sich aber nur in schwie- 
rigen Fällen, die hier noch nicht behandelt werden. 

Ein Datenmodell ist dann ein Geflecht miteinander vernetzter Tabellen, das auf 
zwei Arten dargestellt werden kann: 

1. Als verbal notierte Relationen (= Objekttypen) mit Attributen (s. das gerade dis- 
kutierte Beispiel). Wir nennen dies die Objektsicht. 

2. Als Geflecht von Objekttypen in grafischer Form, die wir in mehreren Skiz- 
zen der vorherigen Kapitel bereits benutzt hatten (vgl. Abb. 3.1, 5.11 und 5.12). 
Dies ist die Beziehungssicht, die in vielen Lehrbüchern in Form von Entity- 
Relationship-Modellen (ERM) die einzige Sicht bleibt. Wir werden uns in Ab- 
schnitt 6.1.2 damit befassen. 

Es dürfte für studentische Leser hilfreich sein, die Relationen auch als Tabellen 
mit Beispielwerten zu sehen. Vor allem Anfänger haben oft Schwierigkeiten, sich die 
Daten abstrakt vorzustellen und die Begriffe Tupel, Domäne und andere mit Inhalten 
zu füllen. 



Tabelle 6.3. Der Grundobjekttyp Mitarbeiter mit Beispieldaten 



Mitarbeiter 

PersonalNr# 

[integer] 


Name 

[string] 


Vorname 

[string] 


Titel 

[enum] 


Geschlecht 

[enum] 


GeburtsDat 

[date] 


Gehalt 

[real] 


4711 


Meier 


Ines 


Dr. 


w 


12.03.1972 


4142,37 


4713 


Schulze 


Hans 


- 


m 


27.06.1984 


2415,00 


4714 


Schulze 


Hans 


- 


m 


14.10.1951 


4623,75 



Tabelle 6.4. Der Vorgangsobjekttyp Leistung als Komposition 



Leistung 

LeistungsNr# 


Datum 


Personal# 






[integer] 


[date] 


[integer] 






101 


21.01.2005 


4713 






108 


15.03.2005 


4711 






LeistungsPos 

LeistungsNr# 


AuftragsNr# 


vonZeit 


Dauer 


Tätigkeit 


[integer] 


[integer] 


[time] 


[real] 


[string] 


101 


18 


07:30 


2,5 


Baustelle herrichten 


101 


18 


10:15 


4,7 


Badewanne einbauen 


108 


18 


11:00 


1,0 


Reklamation prüfen 
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Wir sehen in Tabelle 6.3 Daten für drei Mitarbeiter, von denen zwei Leistungen 
für einen Auftrag kontiert haben. Zur Verdeutlichung wurden die Attributtypen unter 
die Namen geschrieben, so dass vor allem der Typ enum klarer wird. Der Titel 
wäre definiert als 



Titel = {Dr., PhD, Prof., -}, 
wobei ’ - ’ kein Titel bedeutet. 

Auch die Referenzstruktur ist auf der Wertebene besser sichtbar. Sie kann un- 
mittelbar nachvollzogen werden, wobei der ebenfalls referenzierte Typ Auftrag 
weggelassen wurde. Die Tabellen zeigen auch, dass man für ein Exemplar (Tupel) 
nur genau ein Exemplar eines Fremdschlüssels ansprechen kann. So benötigen hier 
die Leistungen verschiedener Mitarbeiter mehrere Zeilen in der Tabelle Leistung. 

Die Konstruktion redundanzfreier Tabellen 

Während Codd in der Originalveröffentlichung nur die erste Normalform gefordert 
hatte, zeigte sich schnell, dass es weiterer Konstruktionshilfen bedarf, um Redun- 
danzfreiheit der Attribute zwischen den vielen Tabellen zu erreichen, aus denen jede 
relationale Datenbasis besteht. Wir werden uns auf die zweite und dritte Normal- 
form beschränken, da die ebenfalls noch häufig diskutierten Normalformen vier und 
fünf gar nicht verletzt werden können, wenn Daten nach dem Ordnungsschema des 
vorigen Kapitels gebildet werden (vgl. auch Vetter, 1991, Kap. 5). 

Die Normalformen sind Regeln, die die Relationen nicht verletzen dürfen, wenn 
sie redundanzfrei und änderungsstabil bleiben wollen. Das Grundprinzip von Rela- 
tionen wurde schon im vorigen Abschnitt genannt: Attribute dürfen nur vom gesam- 
ten Primärschlüssel abhängig sein. Im einzelnen: 

2NF : Die zweite Normalform untersagt, dass Attribute nur von einem Teilschlüssel 
abhängig sind. Dies ist nur bei zusammengesetzten Schlüsseln möglich. 

3NF: Die dritte Normalform verbietet Abhängigkeiten zwischen Nichtschlüssel- 
Attributen. Dies tritt vor allem auf, wenn man Attribute einbringt, die von einem 
Fremdschlüssel abhängig sind. Sie gehören natürlich nur in die Relation, in der 
der Fremdschlüssel Primärschlüssel ist. Wenn Kategorien (s. Abschnitt 5.4.3) 
als Aufzählungstypen realisiert werden, kann die 3NF nicht verletzt werden. 

Hierzu zwei Beispiele: 

Auftrag ( Auf tragsNr# , KundenNr#, Name, Datum): 

3NF verletzt; Name streichen, da Eigenschaft des Kunden und nicht des Auf- 
trags. 

AuftrPos ( Auf tragsNr# , ArtikelNr# , Dimension, Menge): 

2NF verletzt; Dimension streichen, da dauerhafte Eigenschaft eines Artikels 
und nicht temporäre eines Auftrags. 

Zur Normalisierung gibt es einen schönen Merksatz aus dem Benutzerhandbuch 
eines professionellen Datenmodellierungs- Werkzeugs (ERWinSQL), das von großen 
Firmen benutzt wird, z.B. Boeing: 
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“An entity is in third normal form, if every non-key attribute depends on the key, the 
whole key and nothing but the key, so help me Codd.“ 

Es wurde vermieden, den Leser mit der Aufgabe zu belasten, herauszufinden, 
ob eine Abhängigkeit / mmMomöZ oder transitiv ist. Statt dessen halten wir folgende 
Prüffrage für nützlich, die auf jedes Attribut angewendet werden sollte, wenn man 
Relationen bzw. entsprechende Tabellen modelliert: 

Ist das Attribut Eigenschaft des mit der Relation beschriebenen Objektes der 
realen oder gedachten Welt oder ist es Eigenschaft eines anderen Objektes? 

Redundanz und Sichten auf Daten (Views) 

Es wäre noch nach dem Umfang der Redundanzfreiheit in den betrieblichen Daten zu 
fragen. Die Eorderung danach bezieht sich nämlich nur auf originäre Daten, nicht auf 
abgeleitete. Nur originäre und - wie wir aus Kapitel 5 wissen - Bestandsdaten werden 
dauerhaft gespeichert^ und müssen den gesetzten Integritätsbedingungen genügen. 
Deshalb können abgeleitete Daten auch keine dieser Regeln verletzten, da es sie 
nicht gibt. 

Eür informative Zwecke werden sogar häufig Sichten (Views) von Daten erzeugt, 
die Tabellen mit Spalten aus verschiedenen gespeicherten Tabellen erzeugen. Das 
damit zusammenhängende Thema Datenabfragen klammern wir allerdings hier aus. 
Es wird meist im Zusammenhang mit der Sprache SQL behandelt. 

Ein Beispiel für eine Sicht kann bereits eine Rechnung sein. Als gespeicherter 
Vorgang (vgl. Abschnitt 5.5.2) muss sie den Normalformen genügen. Als gedruckte 
Rechnung ist sie dagegen eine Sicht für den Kunden, die selbstverständlich in den 
Positionen außer den Artikelnummern auch deren Bezeichnungen zeigt. Es gilt also: 

Die Normalformen gelten nicht für abgeleitete Daten wie etwa Views. 

Klassifizierende Schlüssel 

Klassifizierende Schlüssel sind langlebig. Sie stammen aus der Erühzeit der „EDV“ 
und der davor liegenden „Karteikarten-Datenverarbeitung“. Diese „Schlüssel“ haben 
ohne Zweifel große Vorteile in der manuellen Handhabung von Daten. Sie sind teil- 
weise sogar in Standards zementiert, wie etwa die Nummern der beiden in Deutsch- 
land üblichen Kontenrahmen, die eine bis zu dreistufige Hierarchie der Kontonum- 
mern vorsehen (Kontenklasse, Kontengruppe, Kontennummer). Sie sind nichts An- 
deres als klassifizierende Zeichenketten, die vor allem der 3NE krass widersprechen, 
wenn sie als ein Attribut behandelt werden. Außerdem sind sie heute in einem be- 
trieblich dynamischen Umfeld sehr problematisch, da die Werte dieser Schlüssel in 
einer Datenbasis vielfach auftauchen und auf komplizierte Weise ausgewertet wer- 
den müssen. So sind informell viele Eälle großer Eirmen bekannt, die klassifizieren- 
de Artikelnummern in SAP-Systeme hinein implementiert haben, was vom Standard 

^ Das Thema Data Warehouse hatten wir ausgeklammert (vgl. Abschnitt 5.2), bei dem auch 
abgeleitete Daten gespeichert werden. 
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der Software natürlich nicht vorgesehen ist. Wie lässt sich mit solchen „Schlüsseln“ 
umgehen? 

So lange ein Teilschlüssel ein oder mehrere Stellen umfasst und nur ein Merkmal 
beschreibt, handelt es sich um Kategorien, die als einzelne Attribute des Typs enum 
zu modellieren sind. Wenn man die alten Werte beibehält, auch wenn sie Lücken 
haben, ist das unproblematisch. Numerische Wertebereiche sollten nicht als Zahlen 
sondern als Zeichen modelliert werden, so dass pro Stelle aus 10 ohne jeden Zusatz- 
aufwand 36 Möglichkeiten werden. Dies schafft Flexibilität für die Zukunft, ohne die 
Gegenwart (Zahl-Zeichen) auszuklammern. Ein Prinzip muss jedoch gewahrt blei- 
ben: 



Attribute beschreiben oder klassifizieren, Primärschlüssel identifizieren und 

tun sonst nichts. 

Gerade klassifizierende Artikelnummern haben sich in der Logistik von Unter- 
nehmen oder bei Fusionen schon mehrfach als Flindernis für effiziente Prozesse her- 
ausgestellt. 

Technisch ist es heute kein Problem, an Bildschirmen oder auf Listen einen klas- 
sifizierenden String aus den Attributwerten zu erzeugen, der dem Benutzer die ge- 
wohnte Nummer liefert. Bedingung für das Gelingen ist allerdings, dass Primär- 
schlüssel als reine Identnummern grundsätzlich von den Datenerfassungsprogram- 
men maschinell generiert werden und sich nicht manuell eingeben lassen, weil sonst 
der Benutzer Semantik in die Nummer hinein bringt und später deren Auswertung 
verlangen wird. 

Die Konsistenz des Datenmodells 

Die Normalformen können redundante Attribute in mehreren Tabellen verhindern, 
sie helfen aber nicht, die Konsistenz des gesamten Modells zu gewährleisten. Doch 
auch hierfür liefert das Relationenmodell eine klare Regel, die für ein Datenmodell 
im Wesentlichen ausreicht.^ Die Regel lautet: 

Beim Anlegen von Daten sind Nullwerte in Schlüsseln nicht erlaubt. 

Doch was sind Nullwerte und was hat das mit dem Anlegen von Daten zu tun? 
Ein Nullwert ist ein „Nicht- Wert“, der von jedem Wert der Wertemenge eines ele- 
mentaren Datentyps verschieden sein muss. Er realisiert die leere Menge 0. Der 
Wert 0 einer integer- Variablen ist selbstverständlich ein gültiger Wert und damit 
kein Nullwert. Wie Datenbanken Nullwerte codieren, braucht man beim Modellie- 
ren nicht zu wissen. Sogar der unmittelbare Benutzer einer Datenbank muss es nicht 
wissen. 

Mit dem logischen Wert null (englisch!) kann man feststellen, ob einem Attribut 
einer Tabellenzeile schon ein Wert zugewiesen wurde. Dies geschieht beim erstmali- 
gen Anlegen der Daten eines Exemplars. So kann es Vorkommen, dass beim Anlegen 

® Es ist hier nicht das Ziel, die praktisch begründbaren Ausnahmen beim Anlegen oder Än- 
dern von Daten in Datenbanken zu behandeln. 
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eines neuen Mitarbeiters das Gehalt zunächst unbekannt ist. Vor der Gehaltsabrech- 
nung kann man dann die Datenbasis maschinell auf unvollständige Tupel überprüfen, 
indem man Nullwerte des Attributs Gehalt abfragt. 

Bei Schlüsseln dürfen keine Nullwerte möglich sein, wenn die Datenbasis kon- 
sistent sein soll. Jetzt kommt unsere Klassifikation aus Kapitel 5 zum Tragen. Wir 
wiederholen und ergänzen hierzu bisherige Aussagen: 

1. Vorgangsdaten sind von Grunddaten abhängig, also ... 

2. ... können Grunddaten niemals Fremdschlüssel auf Vorgangsdaten enthalten. 

3. Grunddaten dürfen keine Fremdschlüssel auf andere Grunddaten enthalten. 

4. Falls jedoch aus praktischen und technischen Gründen Aufzählungstypen als 
Tabellen realisiert sind, können Grunddaten I und II Fremdschlüssel auf Grund- 
daten III (Kategorien) enthalten. 

5. Kategorien dürfen keine Fremdschlüssel enthalten. 

Welche Konsequenz hat dies für die Reihenfolge, in der Daten angelegt werden 
müssen? Die Nullwerte-Regel (s. oben) ist nur dann einzuhalten, wenn folgende Rei- 
henfolge beim Anlegen von Daten beachtet wird: 

1. Kategorien ^ 2. sonstige Grunddaten ^ 3. Vorgangsdaten ^ 4. Abhän- 
gige Tabellen, z.B. in Kompositionen. 

Dies entspricht auch betrieblichen Notwendigkeiten, wenn auch nicht jeder sog. 
„Praxis“. 

6.1.2 Grafisches Objektmodell (Beziehungssicht) 

Dieser Abschnitt führt in die UML-Notation für Klassendiagramme ein und verweist 
kurz auf das verbreitete Entity-Relationship-Modell. Es wird aus der Historie erklärt, 
warum das Relationenmodell fälschlicher Weise den Ruf hat, ein technisches Modell 
zu sein. 

Warum UML statt ERM? 

Teilweise hat Chen (1976) sein Entity-Relationship-Modell als Gegenmodell zum 
Relationenmodell bezeichnet, allerdings nur in dem Kontext, dass es zu dieser Zeit 
drei konkurrierende Datenbankmodelle gab, zu denen das ERM eine semantische 
Verallgemeinerung bilden sollte. Daher rührt wahrscheinlich der Ruf des RM, ein 
technisches Modell zu sein. Ziel von Chen war es, die Semantik der Modelle deut- 
licher zu machen. Das RM verfügte über keine grafische Notation und machte auch 
die Kardinalitäten der Beziehungen nicht deutlich (1:1, 1:N, N:M). Die Kardinalitä- 
ten drücken aus, wie oft ein Entitätstyp mit einem anderen assoziiert ist. In den 80er 
Jahren beschäftigte die Eachwelt auch weniger das Modell RM, sondern die Erage, 
ob es technisch denn möglich sei, eine relationale Datenbank zu bauen. 

Dem Gedanken einer systematischen Modellierung von Unternehmensdaten hat 
sicherlich Chen und nicht Codd zum Durchbruch verhelfen. Zu diesem Technologie- 
transfer hat Scheer (1997, 1. Auflage 1988) maßgeblich beigetragen. In seinem Buch 
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Wirtschaftsinformatik und auch von anderen Autoren (Becker & Schütte, 2004) wur- 
den umfangreiche ER-Modelle als Referenzmodelle beschrieben. Doch die Entwick- 
lung ist inzwischen weiter. Mit UML wurde 1997 der erste international umfassende 
Standard für Grafiken von Informationssystemen gesetzt, inzwischen von der Object 
Management Group (2005) als Version 2.0 herausgegeben. Wir haben diese Notation 
in Kapitel 2 für Prozessbeschreibungen benutzt und können auch hier in Form von 
Klassendiagrammen darauf zurückgreifen. UML erlaubt es, Datenmodelle übersicht- 
licher und an einigen Stellen auch präziser als mit dem ERM darzustellen. Beispiele 
waren bereits in den Kapiteln 3 und 5 benutzt worden. 

Wir könnten auch UML statt des RM für die Objektsicht benutzen, indem Klas- 
sendiagramme mit Attributen verwendet werden. Hierbei ist jedoch die grafische 
Notation von UML sehr umständlich. Das RM erlaubt eine verbale Notation, bei 
der die Relationen gleichzeitig als Tabellenüberschriften für Beispieldaten dienen. 
Dies erscheint zum Lernen der Modellierung und für eine Validation der Modelle 
nützlicher. 

Grafische Notation und Multiplizitäten 

Ein Klassendiagramm ist ein Graph, dessen Knoten Objekttypen bzw. Klassen und 
dessen Kanten Assoziationen oder auch Beziehungstypen zwischen den Objekttypen 
darstellen. Die Kanten sind benannt, denn Assoziationen haben immer eine Seman- 
tik. Sie können Fremdschlüsselbeziehungen sein, aber auch Relationen (Tabellen), 
die mehrere Attribute haben. An den Objektsymbolen stehen die jeweiligen Multi- 
plizitäten, das sind die minimale und die maximale Kardinalität der Assoziation. An 
den Kanten kann man Rollen notieren, was im ERM nicht üblich ist. Dies wird an 
Beispielen verdeutlicht, die in den vorangegangenen Kapiteln schon mit einem in- 
tuitiven Verständnis benutzt worden waren. Sie werden jetzt formal vervollständigt. 




Abb. 6.1. Auftragsbeziehung mit einer Komposition Auftrag 



Abb. 6.1 zeigt eine einfache Auftragsbeziehung als UML- Klassendiagramm. Der 
Auftrag ist ein komplexes Objekt der Art Komposition, die wir schon kennen. Die 
Multiplizitäten drücken aus, wie oft mindestens (linke Kardinalität) und höchstens 
(rechte Kardinalität; *= beliebig oft) ein Objekt mit Exemplaren des anderen Objekt- 
typs assoziiert sein kann. ’O’ bedeutet kein, ’ 1’ ein. ’U alleine bedeutet genau 1. Die 
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Abb. 6.2. Auftragsbeziehung mit aufgelöster Komposition 



Multiplizität ’O..*’ bedeutet z.B. links am Objekttyp Auftrag, dass ein Kunde ’ kei- 
nen bis beliebig viele’ Aufträge erteilen kann. Wir meinen damit allerdings nur die 
Aufträge, die gleichzeitig als Daten gespeichert werden sollen. Dies ließe sich auch 
mit einem ERM ausdrücken, benötigt aber bei einer Auflösung der Komposition als 
ERM schon Sondersymbole, weil es beim ERM keinen Verfeinerungsmechanismus 
gibt. In UML ist das nicht nötig, wie Abb. 6.2 zeigt. Dort sieht man die elementare 
Tabellenstruktur, die wir aus Abb. 5.11, Seite 79 bereits kennen. Die Raute in Abb. 
5.11 impliziert die Multiplizität ’T und kennzeichnet die Struktur als Kompositi- 
on. Abb. 5.11 ist also formal korrekt. Man sieht auch, dass die Dekomposition neue 
Multiplizitäten zeigt, aber die von der Komposition Auftrag nach außen gehenden 
nicht ändert. Wenn man versuchen würde, Auftrag gemäß Abb. 6.1 als elementare 
Tabelle zu modellieren, würde man schnell grobe Verletzungen der 2NF oder 3NF 
und redundante Daten feststellen. 

Wir betrachten als zweiten Fall mit Abb. 6.3 einen Ausschnitt aus einem Bei- 
spiel von Chen (1976, 19) zum Projektmanagement. Zwischen den Objekttypen 
Mitarbeiter und Proj ekt gibt es zwei Assoziationen mit verschiedenen Mul- 
tiplizitäten. Die vom Objekttypnamen abweichende Rolle ist explizit angegeben. 





1..* arbeitetin 


0..* 




Mitarbeiter 


1 leitet 


0..* 


Projekt 




Projektleiter 





Abb. 6.3. Mehrfache Assoziation mit Rollen 



Auch Stückliste und Teileverwendung aus Abb. 5.5, Seite 65 können mit Abb. 6.4 
jetzt genau angegeben werden. Ein Teil enthält kein oder bis zu beliebig viele Teile. 
Wenn es kein Teil mehr enthält, ist es ein Blatt des Baumes, den jede Stückliste bildet, 
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enthält ► 



1 










Stückliste 


Teü 


0..* 






0..* 


Teilever- 


1 





Wendung enthalten_in ► 



Abb. 6.4. Stückliste und Teileverwendung als Rollen 



bzw. hat bei der Stücklistenauflösung die Rolle Einzelteil. Die Teileverwendung ist 
die Inverse einer Stückliste: Wo ist das Teil eingebaut? Ein Teil, das in keinem Teil 
eingebaut ist (’O..’), ist die Wurzel eines Baumes, bzw. ein Endprodukt oder eine 
verkauftsfähige Baugruppe (Ersatzteil). UML sieht vor, bei Bedarf eine Leserichtung 
für Assoziationen anzugeben. Dies ist bei den doppelt rekursiven Strukturen um Teil 
herum angebracht, so dass z.B. gelesen werden kann: „Teil enthält Teil in der Rolle 
Stückliste“. Als Standard ohne Kennzeichnung gilt oben unten und links rechts. 
Jetzt gilt es, größere Modelle zu erstellen. 

Das Ordnungsschema SERM 

Betriebliche Datenmodelle können auch in der Beziehungssicht durch die große 
Zahl von Objekt- und Beziehungstypen schnell komplex und unübersichtlich wer- 
den. Hierfür haben Ferstl & Sinz (2001, Abschn. 5.2.3) das Strukturierte Entity- 
Relationship-Modell (SERM) entwickelt, das den Graphen eines Datenmodells nach 
zunehmender Existenzabhängigkeit von links nach rechts ordnet. Wir haben mit un- 
serem Ordnungsschema der betrieblichen Daten ebenfalls eine solche Hierarchie 
der Existenzabhängigkeiten angegeben und im vorigen Abschnitt mit der Anlege- 
Reihenfolge auch angewendet. Welcher Art die Graphen sind, ist für die Idee des 
SERM belanglos. 



Abb. 6.5 zeigt ein solches Modell, in das ganz rechts auch aggregierte Daten 
grob eingezeichnet sind, gekennzeichnet mit einem Der entsprechend verhan- 
delte Auftrag stellt für den Anbieter sowohl eine Vorkalkulation dar als auch einen 
für den Kunden transparenten Arbeitsplan. Im Baugewerbe ist diese Art von Auf- 
trag als „Leistungsverzeichnis“ sogar vorgeschrieben. Der Auftrag wird durch Leis- 
tungspositionen der Mitarbeiter des Auftragnehmers erfüllt. Die Summierung aller 
Positionswerte des Auftrags ist sein Soll, die Summe der Leistungspositionen sein 
Ist, die Differenz, sehr grob mit Vollkosten gerechnet, sein Gewinn oder Verlust. Der 
Leser beachte, dass im Unterschied zu Abb. 5.12, Seite 81 sichjetzt die Leistungspo- 
sition auf die Auftragsposition bezieht und nicht auf den gesamten Auftrag. Nur so 
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Abb. 6.5. Bearbeitung eines Kundenauftrags in Einzelfertigung 



wird ein exaktes Controlling der Vorkalkulation ermöglicht, denn bei einer starken 
Abweichung des Ist vom Soll möchte man wissen, wo Differenzen auftreten. Solche 
Strukturunterschiede sind nicht formal, sondern semantisch begründet. 

Zur Übung möge der Leser von den Objekttypen Artikel, Mitarbeiter 
und Leistungsposition eine Objektsicht in Form von Relationen erstellen. In 
der Zuordnung der Attribute stecken viele semantische Detailentscheidungen. Erst 
nach einer solchen Validation kann gesagt werden, ob die Beziehungssicht rich- 
tig und einfach genug ist. Ein Hinweis: Es vereinfacht ein solches Modell erheb- 
lich, wenn man dem Objekttyp Artikel ein Attribut Typ mitgibt, der als Auf- 
zählungstyp wie folgt deüniert sein könnte: Typ = {Material, Geselle, 
Meister}. Auch eine Dienstleistung kann ein Artikel sein. Trennt man Ma- 
terial und Dienstleistung, wird das Modell sehr kompliziert. 



Ein zweites Beispiel aus dem Produktionsbereich zeigt weitere Grunddaten, 
und zwar Arbeitsplatz, Arbeitsplan mit Arbeitsgang und Werkzeug. 
Werkzeug ist ein unabhängiger Objekttyp, gehört also zu den Grunddaten II, Ar - 
beitsplatz und Arbeitsplan sind von Anlage und Teil abhängige, ori- 
ginäre Plandaten, die zu jeder Eertigung gehören, die mit Leistungslöhnen arbeitet. 
Die Komposition Arbeitsplan ist natürlich kein Vorgangsobjekttyp. Die Bezie- 
hungssicht zeigt das Modell in Abb. 6.6. Sie wird nur verständlich sein für den, der 
eine industrielle Eertigung kennt. Andere Leser werden sich Vorstellungen machen, 
was hier dargestellt wird, vermutlich aber jeder andere und sehr wahrscheinlich al- 
le, die die Realwelt nicht kennen, fachlich falsche. Hier kann die Objektsicht nicht 
Alles, aber Vieles durch Offenlegung von Attributen und Verweisen präzisieren. Der 
fachkundige Leser möge allerdings Nachsicht mit einigen starken Vereinfachungen 
üben, vor allem den Kardinalitäten ’l’ bei Anlage und Werkzeug. Wer eine rea- 
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Abb. 6.6. Arbeitsplanung für die Fertigung 



litätsnähere, aber auch sehr viel komplexere Darstellung sucht, der sei auf Scheer 
(1997, Abb. B. 1.105) verwiesen. 

Die Objektsicht wird in Form von Relationen gegeben, bei denen die meisten 
Namen ausreichend Semantik transportieren oder tiefer gehende Fragen induzieren 
sollten. Wir verwenden hier zum ersten Mal einen speziell gekennzeichneten Alter- 
nativschlüssel (Suffix ’A’) parallel zum zusammengesetzten Primärschlüssel. Dieser 
neue Schlüssel wird in einer anderen Relation als Fremdschlüssel henötigt und dort 
auch wie ein solcher benutzt. Dies macht das Modell an der Stelle der Verwendung 
des Fremdschlüssels besser verständlich. 

Anlage ( AnlagenNr# , Bezeichnung, . . , Standort) 

Arbeitsplatz ( AnlagenNr# , Quell . Teil# , Bezeichnung, 
Kostenstelle, ArbP lat zNr#A) 

Teil ( TeilNr# , Rolle , Bezeichnung , . .Dimension) 

Arbeitsplan ( ArbPlanNr# , Ziel . TeilNr# , Text) 

ArbeitsGang ( ArbPlanNr# , ArbPlatzNr# , Tätigkeit , Vorgabezeit , 
Quell . TeilNr#, WerkzeugNr#) 

Werkzeug ( WerkzeugNr# , Bezeichnung , Bereich) 

Das Modell geht vereinfachend davon aus, dass ein Arbeitsplatz für die Herstel- 
lung eines bestimmten Teils hergerichtet ist und dass es dafür ein spezielles Werk- 
zeug gibt. Hier ist es unbedingt ratsam, mit Rollennamen bei den Fremdschlüsseln zu 
Teil zu arbeiten. Ein Arbeitsplan beschreibt z.B. die Herstellung eines Einzelteils 
(Rolle Ziel-), für das in Arbeitsgängen Ausgangsmaterialien benötigt werden (Rolle 
Quell-). Der Leser möge beachten, dass dies nur ein sehr einfach gehaltener Plan 
ist. Wenn in der konkreten Produktion die Leistungen hinzu kommen, möglicherwei- 
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se noch in Verbindung mit den Auftragspositionen eines Kundenauftrages (s. Abb. 
6.5), wird das Modell wirklich komplex. Unser Beispiel dürfte aber für eine Einfüh- 
rung genügen und auch dafür, einen Hintergrund zu dem im übernächsten Abschnitt 
gezeigten Unternehmens-Datenmodell zu bekommen. 

Davor soll die Vorgehensweise bei der Datenmodellierung zusammengefasst 
werden. 

6.1.3 Vorgehensmodell zur Datenmodellierung 



^^[Datenmodell 
wird gebraucht] 




^normalisieren^ 



y 

Objektsicht 

vervollständige: 





validieren ^ 



[korrektes 

Datenmodell] 



Abb. 6.7. Vorgehensmodell zur Erstellung von Datenmodellen 
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Es ist nicht möglich, korrekte Datenmodelle nur in der Objektsicht oder nur in 
der Beziehungssicht zu erstellen. Entweder geht jeder Überblick verloren, oder es 
werden Strukturen erzeugt, die semantisch nicht haltbar sind. Vor diesem Hinter- 
grund ist das Aktivitätsdiagramm Abb. 6.7 zu sehen, das zwei mögliche Wege zeigt. 
Der eine verläuft bottom-up, also vom Detail zur Zusammenfassung, der andere top- 
down, also in schrittweiser Verfeinerung. Teilweise ist es eine Sache persönlicher 
Vorlieben, teilweise auch eine der Erfahrung, welchen Weg man wählt. 

Anfängern ohne Kenntnisse des Diskursbereiches sei empfohlen, auf der seman- 
tischen Ebene bottom-up mit Tabellen und Beispielwerten zu beginnen, da ihnen 
noch das nötige Vorstellungsvermögen fehlt. Sie müssen sich aber nicht mühsam 
„hochnormalisieren“, wie dies in Lehrbüchern empfohlen wird (s. z.B. Stahlknecht 
& Hasenkamp, 2005, 175), sondern können sich an den hier oder von anderen Auto- 
ren angegebenen Referenzstrukturen orientieren. Dabei ist aber die Problemstellung 
sorgfältig zu prüfen, denn Referenzmodelle bergen die Gefahr in sich, als „Kochre- 
zepte“ benutzt zu werden. 

Erfahrene Modellierer haben gewisse Referenzstrukturen im Kopf und können 
auch von den betriebswirtschaftlichen Einzelheiten abstrahieren, da sie den Diskurs- 
bereich kennen. Sie gehen eher den Weg top-down über die Beziehungssicht. Wenn 
Anfänger, gerade auch bei Verwendung des ERM, mit dieser Sicht beginnen, gera- 
ten ihnen grafische Gebilde mit manchmal haarsträubenden semantischen Fehlern. 
Da werden Attribute als Entitytypen modelliert oder Beziehungstypen geschaffen, 
die unsinnig sind. Die Modelle werden regelmäßig zu kompliziert. Dies kann auf der 
empirischen Basis von rund 2500 Klausuren (Studierende der Betriebswirtschaft) im 
Verlauf von fast 10 Jahren behauptet werden. 

Abb. 6.7 zeigt aber auch, dass in beiden Fällen eine Validation notwendig ist. 
Weder ERM noch UML bieten hierzu formale Regeln. Diese liefert nur das Rela- 
tionenmodell, wobei auch hier eingeschränkt werden muss, dass wir bei vielen se- 
mantischen Fragen über keine formalen Regeln verfügen, die zu richtig oder falsch 
Auskunft geben. 

Zusammenfassung Abschnitt 6.1 

o Für ein Datenmodell benötigt man sowohl eine Objektsicht (Semantik der Attri- 
bute) als auch eine Beziehungssicht (Semantik der Assoziationen). Die Reihen- 
folge ist eine Frage der Erfahrung und persönlicher Vorlieben. 

1. Objektsicht 

o Relationen sind Mengen in Form von Tabellen mit elementaren Datentypen 
in den Spalten als Teilmengen. 

o Jede Spalte bildet über den Datentyp eine zulässige und über die Menge der 
Zeilen der Tabelle eine tatsächliche Wertemenge. 
o Aufzählungstypen sind im Modell keine Tabellen, sondern Attribute mit stark 
eingegrenztem Wertebereich. 

o Die Zeilen einer Tabelle bilden die Exemplare oder auch Tupel. 




104 



6 Die Struktur betrieblicher Daten 



o Exemplare werden über Primärschlüssel identifiziert und können Attribute 
als Fremdschlüssel enthalten, deren Werte auf Exemplare anderer Relationen 
zeigen. 

o Klassifizierende „Schlüssel“ werden in Attribute aufgelöst, die als Aufzäh- 
lungstypen modelliert sind. 

o Schlüssel dürfen keine Nullwerte enthalten. 

o 2NE und 3NE helfen, redundante Attribute in mehreren Tabellen zu vermei- 
den. 

2. Beziehungssicht 

o Die Beziehungssicht eines Datenmodells kann mit Klassendiagrammen er- 
stellt werden, die benannte Assoziationen, Rollen und Multiplizitäten zeigen. 

o Die Assoziationen entsprechen den Rauten des ERM. 

o Größere Modelle sollte man nach einem Ordnungsschema zeichnen. Ein sol- 
ches ist SERM, bei dem die Objekttypen mit nach rechts zunehmender Exis- 
tenzabhängigkeit dargestellt werden. 

3. Vorgehen 

o Jedes Modell muss semantisch und formal validiert werden. 

Es folgt ein einfaches Unternehmens-Datenmodell, das die Möglichkeiten und 
Grenzen der Beziehungssicht zeigt. 



6.2 Unternehmens-Datenmodell des Industriebetriebs 

Das Modell in Abb. 6.8 zeigt die wichtigsten der hier besprochenen originären Daten, 
erst die Grund-, dann die von ihnen abhängigen Vorgangsdaten, und ganz rechts 
einige Beispiele für abgeleitete Daten. Alle Objekttypen sind generalisiert, so dass 
sie nur durch weitere Verfeinerung als elementare Tabellen realisiert werden können. 
Deshalb macht die Angabe von Multiplizitäten keinen Sinn. Aus dem gleichen Grund 
wurden die Typen Lager ^ Bewegung ^ /Bestand weggelassen. 

Bei den Grunddaten nehmen Teil und Mi tarbei ter eine dominierende Stel- 
lung ein, weil von ihnen je nach Rolle unterschiedliche Beziehungstypen ausgehen, 
die mit verschiedenen Vorgängen assoziiert sind. Nach dem hier Besprochenen ist 
es natürlich, dass alle Vorgangsdaten als aggregierte und nicht als elementare Ob- 
jekttypen gezeigt werden. Mit Arbeitsplatz wird ein wichtiges Beispiel für die 
Verknüpfung von Grunddaten gezeigt. Der eigentliche Produktions- und der Einanz- 
bereich sind aus didaktischen Gründen nur angedeutet. 
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6.3 Wiederholung 

• Die Basisstruktur von Datenobjekttypen ist die Tabelle, deren Spalten als Attri- 
bute die kleinsten gespeicherten Einheiten betrieblicher Daten sind. 

• Mit Hilfe der Datenmodellierung kann man sicherstellen, dass Attribute redun- 
danzfrei Datenobjekten zugeordnet werden. Dies unterstützen die drei Normal- 
formen. 

• Die Konsistenz der Verknüpfung der Datenobjekte kann über Fremdschlüssel 
überprüft werden. 

• Größere Datenmodelle kann man in der Beziehungssicht grafisch mit SERM dar- 
stellen. 

• Eine Validierung während und am Ende einer Modellierung ist unerlässlich. 

• Für validierbare Datenmodelle benötigt man sowohl eine Objektsicht, die Ob- 
jekttypen mit Attributen modelliert, als auch eine Beziehungssicht, die die Asso- 
ziationen zwischen den Objekttypen zeigt. 
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Anwendungssysteme 



Eine Reihe von Funktionen der betrieblichen Prozesse (s. Kapitel 2) wird nicht ma- 
nuell, sondern maschinell ausgeführt oder unterstützt. Dies geschieht durch Anwen- 
dungssysteme, mit denen betriebliche Daten erzeugt und ausgewertet werden. Sie 
werden im Folgenden besprochen. 



7.1 Was sind Anwendungssysteme? 

7.1.1 Das betriebliche Informationssystem 

Wenn man richtig verstehen will, was betriebliche Anwendungssysteme sind, muss 
man einen größeren Kontext betrachten. Wir hatten uns, dem allgemeinen Sprachge- 
brauch folgend, in Abschnitt 2.1.2 für einen synonymen Gebrauch von Funktion und 
Aufgabe entschieden. Jetzt müssen wir genauer werden. Der Mensch bekommt vom 
Unternehmen Aufgaben zugewiesen, bei deren Erledigung ihn Anwendungssysteme 
unterstützen. Mensch und Automat zusammen bilden den Aufgabenträger. 



— Aulgabenträger — 

Automat Mensch 

(Software + Daten) (Organisation) 



Anwendungs- 

system 

(Programme) 



abgeleitete 



ongmare • 
Daten 



Manager, 

Sachbearbeiter 



• Sachbearbeiter 



Abb. 7.1. Informationssystem mit maschinellen und menschlichen Aufgabenträgem (nach 
Ferstl & Sinz, 2001, 4) 
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Ein betriebliches Informationssystem hat immer zwei Aufgabenträger, Software 
als Automaten und den Menschen als Datenerzeuger und Entscheiden Der Automat 
kann viele seiner Eunktionen nur auf der Basis gespeicherter Daten ausführen. Abb. 
7.1 zeigt diesen Sachverhalt, um deutlich zu machen, dass Anwendungssysteme das 
Organisationssystem des Unternehmens überwiegend interaktiv unterstützen. Diesen 
Aspekt sollten wir noch einmal aus der Sicht des Menschen als Benutzer betrachten. 

7.1.2 Wie arbeitet Dialogsoftware? 

Betriebliche Anwendungssysteme sind Dialogsysteme, die Programme sind über- 
wiegend Dialogbausteine. Ein Dialogbaustein wickelt mit dem Benutzer eine Mensch- 
Maschine-Kommunikation ab, die Dialog genannt wird. Eingebettet in das System 
sind Bausteine für automatisch ablaufende Prozesse {Batchprozesse), die entweder 
vom Benutzer in einem Dialog gestartet werden oder bei Eintreten bestimmter Ereig- 
nisse automatisch anlaufen. Batchprozesse sind häufig automatisierte Transformati- 
onsaufgaben (vgl. Abschnitt 2.1.2). Ein Dialog verläuft synchron zum Arbeitspro- 
zess des Benutzers, ein Batchprozess asynchron (vgl. Kapitel 4). 



Q 








Software 






Daten- 


► 


(Automat) 




CTSpeicher"^ 



Benutzer- 

oberfläche 



Datenbank- 

Zugriffe 



Abb. 7.2. Oberfläche und „Innenfläche“ einer Dialogsoftware 



Die Programme sind Automaten, die irgendwann vorher ein Entwickler program- 
miert hat. Abb. 7.2 zeigt dies schematisch, Tabelle 7.1 erläutert, was bei dieser Kom- 
munikation jeweils geschieht. Sie hat drei Varianten: 1. die Datenpflege, 2. die Ab- 
frage von Information, 3. den Abruf von Batchprozessen. 



Tabelle 7.1. Interaktion zwischen Benutzer und Software 



1 

2 

3 



Benutzer 

Tätigkeit 

Daten erzeugen und eingeben 
Selektionsdaten eingeben, 
Information bewerten 
Prozess wählen, 
andere Aufgabe ausführen 



Software 

Antwort 

“gespeichert“ 

Information 

“gestartet“ 



Funktion 

Integritätsbedingungen prüfen 
Daten aus Speicher zusammenstellen 

Prozess ablaufen lassen 



Der Leser beachte bei Schritt 1 in Tabelle 7.1, dass die Software die Integritäts- 
bedingungen (vgl. Abschnitt 3.4.2) eingegebener Daten prüft und bei Eehlern das 
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Abspeichern verweigert. Auch in den Fällen 2 und 3 gibt es Fehlermeldungen des 
Automaten, z.B. wenn die als Information gewünschten Daten nicht gespeichert sind 
oder der Batchprozess nicht anlaufen kann. Ein Anwendungssystem muss auf jede 
betrieblich unerwünschte Eingabe des Benutzers eine Eehlermeldung bereit halten. 
Der Benutzer hat mit der „Innenfläche“ der Software, an der sie auf die Datenbasis 
zugreift (s. Abb. 7.2), nichts zu tun. Er sieht sie nicht und muss auch nicht wissen, wie 
zugegriffen wird. Der Benutzer sieht aber sehr wohl die Benutzeroberfläche, auch 
Benutzerschnittstelle genannt. Sie ist wesentlicher Teil seines Arbeitsplatzes und 
muss so gestaltet sein, wie er denkt und nicht wie vielleicht ein Softwareentwick- 
ler gedacht hat. Also muss er die Strukturen sehen, die seiner betrieblichen Aufgabe 
entsprechen. Die interne Softwarestruktur, die mit der Datenbasis verknüpft ist, und 
die Benutzeroberfläche können verschiedenen Strukturierungsregeln folgen. 

Die „betriebliche Aufgabe“ des Routinebenutzers ist es in allen drei Schritten, 
Daten einzugeben. Diese Daten sind strukturierte Daten, wie sie die vorangegange- 
nen Kapitel bestimmt haben. Bei den Schritten 2 und 3 der Tabelle ist das nicht ganz 
so offensichtlich wie bei Schritt 1 (Datenpflege). Beim Informationsabruf sind fast 
immer Selektionsdaten einzugeben (Objekt wie Kunde oder Artikel; Zeiträume; Ka- 
tegorien, über die verdichtet werden soll), beim Abruf von Batchprozessen häufig. 
Im Zweifel degenerieren die Eälle 2 und 3 zum reinen Abruf vordeflnierter Pro- 
gramme, die keine Steuerungsdaten benötigen. Dies nennt man Auswahl, die heute 
meist mit einem Mausklick erledigt wird. Warum so ausführlich? Es ist wichtig zu 
verstehen, dass betriebliche Anwendungssysteme sich beim Dialog des Benutzers 
prinzipell von Office-Systemen, die einige Leser kennen werden, unterscheiden. 

Bei Office-Systemen entscheidet der Benutzer bei fast allen Teilfunktionen 
über richtig oder falsch. Bei Anwendungssystemen sind durch die Typisie- 
rung der (strukturierten) Daten viele Korrektheitsprüfung durch den Auto- 
maten möglich und aus Sicht des Unternehmens auch erstrebenswert. Dies 
geht mit unstrukturierten Daten nicht. 

Mit diesen Vorinformationen können wir uns der Frage zuwenden, wie Anwen- 
dungssysteme strukturiert sind oder sein sollten. 



7.2 Sichten auf Anwendungen 

Als Strukturierungsmöglichkeit für Anwendungssysteme gibt es drei Möglichkeiten: 
Funktionen, Prozesse und Daten. Auch dies sind Sichten. Sie werden daraufhin un- 
tersucht, ob sie für eine Struktur der Anwendungssysteme geeignet sind. 

Traditionell orientierte man sich an Funktionen, und zwar sowohl in der Wissen- 
schaft als auch in den Unternehmen. Mertens (1978) folgte dieser damals üblichen 
Sicht, angereichert um viele Fallbeispiele aus der Wirtschaft. Die funktionsorientier- 
ten Anwendungssysteme führten jedoch schnell zu gravierenden Integrationsproble- 
men, weil der reale Betrieb Prozessen folgte und nicht Funktionen (s. Abschnitt 2.2, 
Seite 10) und so inkonsistente Daten entstanden. Die funktionalen Systeme speicher- 
ten logisch gleiche Daten in jedem Baustein und damit redundant. Hierdurch wurden 
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Fakten, z.B. zu Produkten, mehrfach gespeichert und von verschiedenen Organisati- 
onsbereichen unterschiedlich definiert und gepflegt. 

Man darf jedoch die funktionale Sicht nicht als reine Flistorie abtun. Wie fast al- 
le betriebswirtschaftlichen Lehrbücher zeigen, wird auch heute noch überwiegend 
funktional gedacht. Dies entspricht vermutlich einer allgemeinen Denkweise des 
Menschen, denn wir fragen zuerst „Was soll ich tun?“ und erst dann nach den Ob- 
jekten (Material, Flilfmittel, Daten): „Womit und woran soll ich es tun?“. 

Scheer (1997) sah das Unternehmen prozessorientiert, aufgeteilt noch einmal 
in die Einzelsichten Organisation, Funktion und Daten. Von der Prozess-Sicht wis- 
sen wir aus Abschnitt 2.3.2, Seite 18, insbesondere aus Abb. 2.7, dass wir damit 
zwar Vorgangsdaten in Prozessen integrieren, die Grunddaten aber gar nicht „se- 
hen“. Dies gilt auch für den Vertriebsprozess, der sich mit einem generalisierten Ob- 
jekttyp Vertriebsbeleg beschreiben ließ (s. Abb. 5.10, Seite 78). Die Grund- 
objekttypen Kunde und Teil hinter den Ausprägungen des Vertriebsbelegs sind 
Vorbedingung für die Existenz vieler Vorgangsobjekttypen. In welchem Dialogbau- 
stein soll die Pflege der Grunddaten stattfinden? Weiterhin sehen wir mit einer reinen 
Prozess-Sicht nicht die Bestandsobjekttypen /Lager und /Konto, von denen wir 
aus Kapitel 5 (Dateninhalte) wissen, dass sie ebenfalls vom Vertriebsprozess berührt 
werden. Also scheint auch die Prozess-Sicht nicht gut geeignet zu sein, zusammen- 
gehörende Anwendungssysteme zu definieren. 

Es bleiben die Daten. Eine Daten-Sicht wird in den Wirtschaftswissenschaften 
nicht verfolgt, spielt aber in der Informatik eine große Rolle. Die in diesem Buch 
verwendete grafische Norm UML versteht sich als objektorientiert (Object Mana- 
gement Group, 2005). Mit Objekt sind Datenobjekte gemeint. Die objektorientierte 
Sicht kapselt Datenobjekte mit den Operationen, die auf die Objekte angewendet 
werden können (anlegen, ändern, löschen etc.). Man erhält so Klassen, die als Bau- 
steine für Softwaresysteme dienen sollen, die deren Struktur (Daten) und Verhalten 
(Operationen) integrieren. Dies ist jedoch eine Sicht, wie man sie zur Entwicklung 
von Software benötigt, nicht zur Benutzung. Wir verwenden hier die grafischen Ele- 
mente von UML, ohne auf die tiefer gehende Sicht der Objektorientierung einzuge- 
hen. Dies hat offensichtlich in der Prozess-Sicht des Kapitels 2 als auch in der Daten- 
Beziehungssicht des Kapitels 6 funktioniert. Im Übrigen ist die Objektorientierung 
als „Allheilmittel“ auch in der Informatik nicht unumstritten (Broy & Siedersleben, 
2002). Also löst die Sicht auf Daten das Problem der Struktur von Anwendungssys- 
temen ebenfalls nicht. 

Es gibt offenbar keine einfachen Rezepte. Keine der drei Kategorien alleine ist 
ein sinnvolles Gliederungskriterium. 

Die längere Diskussion wäre entbehrlich gewesen, würden uns nicht heute rea- 
le Systeme begegnen, die nach verschiedenen Prinzipien strukturiert sind. Wie Abb. 
7.2 andeutet, kann die an der Benutzeroberfläche gezeigte Struktur von der eigent- 
lichen Softwarestruktur völlig abweichen. Technisch ist es möglich, jede beliebige 
Struktur darzustellen. Flierzu zeigt Tabelle 7.2 zwei Beispiele für ein sehr kleines 
und ein sehr großes System. Die Reihenfolge der Punktionen in den Tabellenzeilen 
hat zunächst keine Bedeutung. Die Tabelle orientiert sich an der ersten Spalte, in 
der über dem Trennungsstrich das ursprüngliche Basissystem definiert ist. Die mit 
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Tabelle 7.2. Funktionen zweier Standard-Anwendungssysteme 

Navision® SAP R/3® 



2001 


2005 


2002 


Finanzbuchhaltung 


Finanzbuchhaltung 


FI - finance 
CO - Controlling 




Banksteuerung 


in FI 


Material/Logistik 


Lager 


MM - material management 


Verkauf 


Debitoren & Verkauf 


SD - shipment & delivery 




Marketing & Vertrieb 


in SD 


Einkauf 


Kreditoren &Einkauf 


in MM 


Ressourcenverwaltung 


-l-Ressourcenverwaltung 


in PS 


Projektplanung /-abwicklung 


-l-Proj ektverwaltung 


PS - project System 


- 1 - Anlagenbuchhaltung 


- 1 - Anlagenbuchhaltung 


AM - asset management 


-l-Lohn und Gehalt 


Personalverwaltung 


HR - human ressources 


-l-Produktionsplanung 


-l-Produktionsplanung 


PP - production planning 


und -Steuerung (PPS) 


und -Steuerung (PPS) 


PM - production maintenance 
QM - quality management 



’-h’ gekennzeichneten Bausteine werden vom Hersteller extra berechnet. Die SAP 
AG berechnet alle Bausteine separat. Die Preismodelle der Hersteller von Standard- 
Anwendungssystemen beziehen die Anzahl der am System tätigen Benutzer mit ein. 

Das System Navision ist für kleine Unternehmen konzipiert. Es wurde 2002 von 
der dänischen Firma Damgaard Axapta an Microsoft verkauft. Die zweite Spalte 
für das Jahr 2005 zeigt, dass ein anderer Anbieter mit demselben System über die 
Benutzeroberfläche andere Schwerpunkte setzen kann. Dies hat die SAP AG mit R/3 
inzwischen mit der Oberfläche Netweaver® auch getan, die sich allerdings statisch 
(z.B. in einem Buch) kaum darstellen lässt. Es gibt keine standardisierte Struktur 
mehr, sondern jede Installation wird für den Kunden konfiguriert, in der Feinstruktur 
sogar bis auf die Bedürfnisse des jeweiligen Organisationsbereichs. 

Die „Ressourcenverwaltung“ betrifft bei Navision lediglich die von Projekten 
betroffenen Ressourcen und nicht etwa Anlagen u.ä. Diese Funktion ist ein Beispiel 
für eine historisch entstandene Insellösung, wie sie sich in vielen anderen Systemen 
auch finden ließe. Der Name einer Funktion sagt manchmal sehr wenig über ihren 
Inhalt aus. 

Es ließen sich noch viele solcher Beispiele mit jeweils anderen Schwerpunkten 
und Bezeichnungen für Funktionen aufzählen, ohne dass dies einen grundsätzlichen 
Erkenntniswert hätte. Wir könnten uns auch auf die Benutzeroberfläche beschrän- 
ken, wenn da nicht die Daten wären, die der Struktur der Funktionen nicht folgen, 
insbesondere die Grunddaten. Deshalb erscheint die folgende generelle Aussage an- 
gemessen: 

Anwendungssysteme folgen für den Benutzer einer funktionalen Strukur, 
es dürfen dabei jedoch keine Datenobjekttypen „geschnitten“ werden. Dies 
bedeutet, dass sich alle Operationen zusammen mit den Daten in demselben 
interen Baustein befinden müssen. 
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Was das konkret heißt, wird sich im Verlauf des nächsten Abschnitts zeigen. 



7.3 Funktionsbausteine 

Der Leser mit Informatik-Kenntnissen möge nicht erschrecken, wir reden über eine 
Sicht und nicht eine Struktur von Software.* Diese ist nicht das Problem eines Be- 
nutzers von Anwendungssystemen. Wir zeigen Funktionen, allerdings mit Bezug auf 
die zu pflegenden originären Daten. Betriebliche Anwendungssysteme (AWS) wer- 
den im Routinebetrieb zur Datenpflege benutzt. Dabei werden Grunddaten angelegt 
oder geändert und Vorgänge in die Datenbasis eingegeben. Auf Basis dieser Daten 
gibt es dann viele Informationen dispositiver und aggregierter Art. Die Zuordnung 
der Vorgangsdaten zu Funktionen ist für den Benutzer einsichtig (vgl. die Prozesse in 
Kapitel 2), nicht aber die Zuordnung einiger Grunddaten. Sie werden im Zweifel mit 
den Funktionen verknüpft, deren Vorgänge als Erstes benötigt werden. Die Funktio- 
nen werden im Anschluss an einen Überblick in Tabelle 7.3 im Einzelnen erläutert. 
Die erste Spalte der Tabelle stellt einen Bezug zu den Grundfunktionen aus Tabelle 
2.1 auf Seite 8 her. 



Tabelle 7.3. Funktionen industrieller Anwendungssysteme 



Betriebliche 

Gmndfunkt. 


Anwendungssyst. 


GOT 


VOT 


BOT abgeleit. Daten 


Beschaffung 


Einkauf 


Lieferant 

Teil 


Bestellung 


Bestand Materialkosten 




Materialwirtschaft 


Teil 


Zu-/Abgang 


Bestand Bedarf 


Produktion 


PPS 


Teil 

Anlage 

Arbeitsplan 


Prod-Auftrag 
Maschinenbeleg. 
Leistung 
Zu-/ Abgang 


Bestand Auslastung 

Verfügbarkeit 

Ausbringung 


Absatz 


Vertrieb 


Teil 

Kunde 


Vertriebsbeleg 
Zu-/ Abgang 


Bestand Absatz, Umsatz 
Auftragsbestand 




Projekte 


Mitarbeiter 

Anlage 

Budget 


Leistung 

Bestellung 


Kosten / Objekt 
Plan-Ist Budget 




Personalsystem 


Mitarbeiter 


Entgelt 


Kosten 


Finanzen 


Buchhaltung 


Kontenrahmen Buchung 

Kunde 

Lieferant 

Anlage 


Konto Bilanz 
GuV 
Gewinn 



Man sieht, dass die Grundfunktionen aus Tabelle 2.1, Seite 8 nicht überall ei- 
ne direkte Entsprechung in den Anwendungssystemen Anden. Projekte und vor al- 
lem die Materialwirtschaft lassen sich offensichtlich keiner Grundfunktion zuord- 

* Funktionale Softwarestmkturen gelten heute als grober Kunstfehler. 
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nen. Vor allem Letztere ist ein Anwendungssystem mit Querschnittfunktionen, die 
in mehreren Funktionshereichen benötigt werden. Deutlich wird auch die dominie- 
rende Rolle des Grundobjekttyps Teil, der in den Grundfunktionen Beschaffung, 
Produktion und Absatz erforderlich ist. Hervorzuheben ist weiterhin, dass die GOT 
Teil und Mitarbeiter in der Buchhaltung nicht benötigt werden. Dies wird in 
Abschnitt 7.3.8 noch näher beleuchtet. Der sehr große informative Teil der Anwen- 
dungssysteme (s. Abb. 7.1) ist in der Spalte abgeleitete Daten nur mit Beispielen 
angedeutet. Eine umfassende Darstellung betrieblicher Anwendungssysteme bietet 
Mertens (2004). Im Folgenden werden die Anwendungssysteme erläutert. 

7.3.1 Materialwirtschaft 

Die Materialwirtschaft ist das zentrale Anwendungssystem eines Industriebetriebs, 
wenn Waren in Lägern geführt werden. Das entfällt eigentlich nur bei kleinen Hand- 
werkern. Kernfunktion einer Materialwirtschaft sind die Zu- und Abgangsbuchungen 
von Waren und die als Transaktion damit gekoppelte Führung von Beständen, wie in 
Abb. 5.8, Seite 75 behandelt. 

Wenn ein Unternehmen nur eine Lagerbestandsführung betreiben wollte, müss- 
te es auch ein Subsystem Grunddaten Teil {Produkt, Artikel) installieren. Bei SAP 
heißt dieser Baustein Materialstamm. Dass Teil erforderlich ist, lässt sich aus dem 
Primärschlüssel des zentralen Bestandsobjekttyps 

/Bestand ( LagerNr#,TeilNr# , . . .Menge) 

ablesen. Die Grunddaten Teil werden üblicher Weise einem Anwendungssystem 
Materialwirtschaft hinzugerechnet. Das einfache Modell des Lagers aus Kapitel 5 
darf aber nicht zu dem Schluss verleiten, dies sei ein einfaches System. Das Gegenteil 
ist richtig, denn sowohl die zu lagernden Objekte als auch die Lokationen der Läger 
sind vielschichtig. 

Die Objekte kennen wir aus den Rollen der Produkthierarchie in Abb. 5.4, Sei- 
te 63. Vom Typ Material bis zum Verkaufsgebinde finden Lagerbuchungen in völlig 
unterschiedlichen Organisationseinheiten statt. Ein Material wird z.B. ein- und aus- 
gelagert. Das Verkaufsgebinde kann, ohne es dem Lager zu entnehmen, für einen ter- 
minlich gebundenen Kundenauftrag {Terminauftrag) reserviert werden. Hinter der 
Reservierung steckt eine dispositive Abbuchung, denn über die physisch greifba- 
re Ware darf nicht noch einmal verfügt werden. Sie bekommt in einem Attribut 
Zustand den Wert reserviert. Man nennt diese Teilmenge des Bestandes Reser- 
vierungsbestand. 

Neben der betrieblichen Realität Produkthierarchie gibt es die der physischen 
Läger, von denen cs funktionale (Produktion, Absatz) und regionale (Standorte) gibt. 
Mehrere Standorte sind heute selbst bei mittelständischen Unternehmen üblich. Der 
Trend zur Produktionsverlagerung ins „billigere“ Ausland verstärkt dieses Phäno- 
men. Läger werden an vielen Standorten benötigt. Also muss es in den abgeleite- 
ten Daten beim Objekttyp /Bestand Zwischensummen mindestens je Verantwor- 
tungsbereich und Lokation geben. Ein Beispiel folgt weiter unten. 
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Dies führt zu der wichtigen Funktion eines Lagerverwaltungssystems, der Um- 
lagerung. Eine Umlagerung ist eine Transaktion aus einem Abgang in Ort A und 
einem Zugang in Ort B. Oft stehen dahinter physische Transportvorgänge, aber nicht 
immer. Fertig produzierte Güter können sich physisch im Fertigfabrikate-Lager be- 
finden, für die noch eine Stichprobe in der Qualitätskontrolle untersucht wird. Erst 
nach deren positivem Ausgang gibt es eine virtuelle Umbuchung vom Zustand in- 
Prüfung in den Zustand Fertigware. Die Daten müssen dies in Form von Attributen 
abbilden, denn mindestens die Funktion Bestandsbewertung (für die Buchhaltung) 
ist auf diese Attribute angewiesen. 

Mit Logistik wird oft nur die Handhabung physischer Ware assoziiert (s. Domsch- 
ke & Scholl, 2003, 135). Sie ist jedoch maßgeblich von entsprechenden Informatio- 
nen abhängig, die auf Daten (vor allem der Objekttypen Teil, Bewegung und 
/Bestand) beruhen. Hierzu äußern sich Jahnke & Biskup (1999, 89): 

„... denn eine Logistikleistung ist häufig nur so gut, wie die dazugehörige Informati- 
onsleistung.“ 

Dies spiegelt sich bei verteilten und differenzierten Lägern (z.B. Stellplätze) in 
einem Attribut Bewegungsart wider. Zunächst wäre das ein recht einfacher Auf- 
zählungstyp 

Bewegungsart = {Zugang, Umlagerung, Abgang}, 

der jedoch schnell sehr komplex wird, da jede Transaktion aus einem Paar { vonOrt , 
nachOrt} besteht. Damit lassen sich Integritätsbedingungen formulieren, die der 
Logistik die Ordnung geben, die das Unternehmen braucht. Es können schnell 30 
und mehr Ausprägungen sein, die es je Lager und Rolle von Teil gibt. Beispiele 
wären: 

o FF-Lager an Kundenauftrag (= Versand) 
o Zulieferer X an FF-Lager (= Zukauf) 

o Produktion an FF-Lager (von der Qualitätskontrolle freigegebene Ware). 

Es versteht sich, dass die beiden ersten Bewegungsarten nur für verkaufsfähige 
Ware (Rolle Verkaufsteil, s. Seite 67), die letzte nicht für Verkaufsteile ausführbar 
sein darf. So können z.B. unerwünschte Umlagerungen zwischen dezentralen Lägern 
unterbunden werden, indem sie sich einfach nicht buchen lassen. 

Da Bestände in die Bilanz einfließen, muss in Konzernen auch festgehalten wer- 
den, welcher bilanzierenden Einheit (Buchungskreis) die Ware gehört. Wir zeigen 
diese notwendige Leistung eines Lagerverwaltungssystems am Beispiel einer realis- 
tischeren Bestandsrelation. 

/Bestand ( BuchKrs , WerkNr , LagerNr# , LagerBereich# , TeilNr# , 

MindBestand, Menge) 

Man sieht einen sehr langen, zusammengesetzten Primärschlüssel. Wir haben 
hi&r formal den Fall, dass Aufzählungstypen Schlüsselbestandteile, aber keine Fremd- 
schlüssel sind (kein ’#’). Inhaltlich wird jeder gelagerte Artikelbestand einem bilan- 
zierenden Buchungskreis, und außerdem noch Werk, Lager und Lagerbereich 
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zugeordnet. Damit stehen entsprechend differenzierte Informationen für die Logistik 
zur Verfügung. Die Syntax weist mit den Fremdschlüsseln Lager# und LagerBe - 
reich# referenzierte Objekttypen aus (s. Kapitel 6), die spezielle Eigenschaften 
haben werden, z.B. Regaltypen oder Abmessungen. Durch die differenzierten Attri- 
bute ist es möglich, eine einzige Tabelle für alle Artikel, Werke und Buchungskreise 
als Datenspeicher zu betreiben. 

Es dürfte deutlich geworden sein, dass ein Anwendungssystem Materialwirt- 
schaft, selbst wenn es „nur“ eine Lagerbestandsführung enthält, alles Andere als 
trivial und für den Industriebetrieb von großer Bedeutung ist. 

Mittels der hier besprochenen originären und Bestandsdaten lassen sich eine 
Vielzahl von Berechnungen und direkten Informationen gewinnen, zu denen der 
betriebswirtschaftliche Hintergrund etwa bei Jahnke & Biskup (1999, Abschn. 2.3) 
nachgelesen werden kann. Es handelt sich um die folgenden Teilfunktionen des An- 
wendungssystems : 

o Lagerhaltungspolitik (Zeitpunkte Ein- /Auslagerung, Wegeoptimierung, ABC- 
Analyse u.ä.) 

o Lagerhaltungskosten und Lieferfähigkeit 
o Innerbetrieblicher Transport 
o Inventur 
o Bedarfsrechnung. 

7.3.2 Einkauf 

Nach der ausführlichen Behandlung der Materialwirtschaft kann das die Funktion 
Beschaffung unterstützende System Einkauf knapp abgehandelt werden. Bei SAP ist 
es seit den 80er Jahren (R/2) Bestandteil der Materialwirtschaft MM. 

Ein Einkaufssystem benötigt alle Daten der Materialwirtschaft, denen es den 
GOT Lieferant und den VOT Bestellung hinzufügt. Im Abschnitt 5.4.2 auf 
Seite 67 hatten wir den Lieferanten eingeführt und auch einen Verbindungsobjekt- 
typen Lief erantArtikel gezeigt, dessen Eigenschaften lieferantenspezifische 
Artikelpreise waren. Solche Möglichkeiten muss ein Einkaufssystem bieten, damit 
Einkäufer zeitlich (Lieferzeit), sachlich (Qualität) und ökonomisch (Preis) bei ihrer 
Arbeit unterstützt werden. 

Neben der Pflege von Grund- und der Erzeugung von Vorgangsdaten (Bestellun- 
gen) sind die wichtigsten Teilfunktionen 

o Lieferantenauswahl 
o Analyse Beschaffungsmärkte 

o Terminverfolgung (Lieferzeiten, abgestimmt mit der Produktion) 
o Bestellmengenoptimierung (Losgrößen) 
o Zyklische Wiederbeschaffung (Bestellzeitpunkte). 
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7.3.3 Produktionsplanung und -Steuerung (PPS) 

Ein PPS-System ist nicht annähernd so einfach zu standardisieren wie eine Lagerhal- 
tung oder ein Einkaufssystem. Das liegt an den sehr großen Unterschieden bei der 
Produktion von Gütern, die sich sowohl in der Ausbringung pro Zeiteinheit (Menge) 
als auch in der technischen Komplexität gewaltig unterscheiden. 

Die Spanne reicht vom Kreuzfahrtschiff bis zur Toilettenrolle. Das Schiff ist ein 
komplexes System mit einer langen Bauzeit, das viele hoch qualifizierte Arbeitskräf- 
te und spezialisierte Materialien mit umfassender Planung und Steuerung erfordert. 

Die Toilettenrolle wird ohne menschlichen Eingriff bis zum verkauften 10-er-Pack 
vollautomatisch produziert. Hier besteht das Planungs- und Steuemngsproblem dar- 
in, es nie zu unerwünschten Prozessunterbrechungen kommen zu lassen, also die 
Anlage kontinuierlich mit Rohstoffen zu versorgen und zu verhindern, dass sie aus- 
fällt. 

Die Domäne eines PPS-Systems liegt in der Mitte dieser beiden Extreme Einzel- 
und Massenfertigung, d.h. im Bereich der Serienfertigung. Begriffe und Typologien 
von Industrieunternehmen können bei Jahnke & Biskup (1999, Kap.l) nachgelesen 
werden. 

Wir hatten die Daten der Produktion nicht detailliert behandelt, weil man sie 
nur auf Basis einer gewissen anschaulichen Vorstellung von „produzieren“ verstehen 
kann (vgl. auch Abschnitt 5.3). Lediglich in Kapitel 6 war durch ein stark vereinfach- 
tes Beispiel (Abb. 6.6) ein Eindruck von den Grunddaten der Produktion vermittelt 
worden (Arbeitsplatz, Arbeitsplan, Arbeitsgang, Werkzeug). Das generelle Problem 
der Grunddaten eines PPS-Systems besteht darin, die Rollen von Teil (z.B. Mate- 
rial oder Baugruppe) mit Maschinen und Arbeitsgängen in vielen alternativen Struk- 
turen zu verknüpfen. Man kann dasselbe Teil auf verschiedenen Maschinen mit al- 
ternativen Verfahren hersteilen. Ein PPS-System muss die Datenstrukturen abbilden 
können, die eine bestimmte Eertigung benötigt und muss für den wichtigsten Vor- 
gang, den Produktionsauftrag, einfach zu handhabende Datenerfassungsmöglichkei- 
ten bieten. 

Ist das gelöst, können die üblichen Punktionen eines PPS-Systems (vgl. Jahnke 
& Biskup, 1999, Kap. 2) zur Wirkung kommen: 

o Terminliche Bedarfsermittlung: Wann wird ein Material im Produktionsprozess 
benötigt? 

o Kapazitätsplanung: Belegung der Maschinen, auch Einlastung genannt, 
o Ablaufplanung: Erstellen von Netzplänen für die Produktion zu fertigender Pro- 
dukte. 

o Lagerhaltung. 

Eine sehr umfassende und anschauliche Darstellung der Daten und Punktionen 
von PPS-Systemen findet sich bei Kurbel (2005). Die Daten sind als Datenmodelle 
notiert. 
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Auch ein PPS-System benötigt eine Komponente Lagerverwaltung. Es werden 
Materialien für die Fertigung entnommen und ggf. als Baugruppen wieder eingela- 
gert, d.h. sie verändern durch die Wertschöpfung ihre Rolle. Material geht in Einzel- 
teilen und Baugruppen auf. Aber auch innerhalb einer Produktionshalle liegt Ware 
{Zwischenläger). Je nach Unternehmen und Anwendungssystem können auch diese 
als Lagerbestand erfasst werden. Dies spielt vor allem eine Rolle, wenn man den 
Teil Steuerung dieser Anwendungssysteme ernst nimmt. Sie kann nur funktionieren, 
wenn die Zwischenzustände der Produktionsaufträge zeitnah erfasst werden, wenn 
man also nicht nur Plan-, sondern Istdaten hat. Starre, zentralistische Planungssyste- 
me können auf aktuelle Situationen nicht reagieren. Ein kranker Mitarbeiter ist eine 
fehlende Kapazität der Produktion. Zeitnah reagieren kann in einer solchen Situation 
oft nur der Mensch, aber nur wenn er aktuelle Informationen hat. Hierzu äußert sich 
Kurbel (2005, 268): 

„Genau genommen ist der Begriff des ’PPS’-Systems unzutreffend, denn der mit 
dem ’S’ für Steuerung erhobene Anspmch wurde nicht eingelöst.“ 

Ein Beispiel soll demonstrieren, dass man allein mit einer Steuerungs- und ohne 
Plankomponente nicht nur mit neuester Technik große betriebswirtschaftliche Effek- 
te erzielen kann. 

1989-91 wurde für einen Massenfertiger mit vielen ausländischen Produktionsbetrie- 
ben eine Produktionsauftragsverwaltung entwickelt. Sie basierte in der einzigen in- 
ländischen Fabrik auf einem Netzwerk von MS-DOS-Rechnem (Intel 80286!), über 
die Abschlussmeldungen je Produktionsstufe und -auftrag zurückgemeldet wurden. 

Das System konnte auch ohne Netzwerk auf einem einzelnen PC ablaufen und über 
Telefonleitungen Meldungen an die Zentrale geben. Bei Störungen der Leitung sorg- 
te das Protokoll (s. Abschnitt 4.1.2) dafür, dass so lange gesendet wurde, bis der 
Zentralrechner genau einmal die Kommunikation bestätigt hatte. Dies war wichtig 
für den Fall unsicherer Leitungen. Außer in der inländischen Produktion wurde das 
System Anfang 1991 auf Basis je eines einzigen PC in einem Werk in Tschechien 
und in Tunesien in Betrieb genommen. Das System amortisierte sich innerhalb von 
1,5 Jahren über eine drastische Reduktion der Lagerbestände. Die Entwicklungskos- 
ten hatten 1,2 Mio € betragen. Einzelheiten finden sich in Spitta (1997). Das System 
ist seit 14 Jahren (1991-2005) mit geringen Unterhaltskosten in Betrieb. 2003 wurde 
eine Plankomponente von SAP installiert, mit der es jetzt integriert ist. 

Das Beispiel zeigt, dass alleine die Transparenzerhöhung durch aktuelle Istdaten 
dem Menschen als Entscheidungsinstanz diejenigen Informationen liefern kann, die 
er für ein situationsadäquates Handeln benötigt. 

7.3.4 Vertrieb 

Das Anwendungssystem zur Unterstützung der Grundfunktion Absatz wird meist 
Vertriebssystem genannt. Es benötigt ebenfalls die Grundaten Teil und, neu hinzu- 
gefügt, Kunde. Durch den Geschäftsprozess 
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o Auftragsabwicklung bei Einzelfertigung (Abb. 2.7) bzw. 
o Absatz bei Fertigung auf Lager (Abb. 2.4 und Abb. 2.8) 

kennen wir bereits die zu unterstützenden Funktionen: Angebotserstellung (wenn 
nötig), Auftragsbearbeitung, Auftragsüberwachung und Versand. Auch hier ist, außer 
beim Einzelfertiger, das Lager mit /Bestand ein unabdingbarer Datenbestand. Die 
Funktion Fakturierung kann dem Vetrieb zugeordnet sein wie z.B. in Abb. 2.2 oder 
dem Finanzbereich wie in Abb. 2.7. Sie ist fast immer ein Batchprozess, da große 
Mengen Papier zu drucken und zu verschicken sind. 

Beim Auftragseingang (über Bildschirm, Internet, Datentransfer von Großkun- 
den) muss die Lieferfähigkeit geprüft und bei Terminaufträgen Ware im Bestand 
reserviert werden. Beim Versand wird mittels des Lieferscheins die Sendung zusam- 
mengestellt (kommissioniert), vom Lager abgebucht und verschickt. 

Für die Vorstufe der Auftragsabwicklung wird zunehmend das Internet als Platt- 
form für die Produktpräsentation genutzt. Damit werden ggf. aufwändig hergestellte 
und verschickte Kataloge entbehrlich. 

Ein Vertriebssystem liefert eine Vielzahl von Informationen (s. auch Abb. 2.4, 
Funktion Statistik). Als eine wichtige Datenquelle dienen die Aufträge (die Nachfra- 
ge) und die Rechnungen (der Absatz), die zur sog. Vertriebsstatistik zusammenge- 
führt werden. Die andere wichtige Quelle sind heute die Grunddaten Kunde. Früher 
begnügten sich viele Unternehmen mit den Adressdaten, um Ware und Rechnung zu- 
stellen zu können. Seit einigen Jahren hat man allgemein erkannt, dass viele Merk- 
male des Kunden für das eigene Marketing wichtig und auch leicht zu beschaffen 
sind (z.B. Alter, Geschlecht, Kaufgewohnheiten, u.v.a.m.). Auch der Wohnort ist für 
Analysen wertvoll oder die Mobilität, von der man bei Adressänderungen erfährt. 
Man nennt solche Funktionen eines Vertriebssystems heute „neuhochdeutsch“ Cu- 
stomer Relationship Management (CRM). 

Für die „Vertriebsstatistik“ in Abschnitt 5.6 ist heute bei großen Mengengerüs- 
ten eine Datentabelle in einer relationalen Datenbank nicht mehr ausreichend. Hier- 
für werden, gerade im Absatzbereich, separate Softwareprodukte unter dem Namen 
Data-Warehouse als Zusatz zum Standard- Vertriebssystem eingesetzt. 

Standard- Vertriebssysteme sind ausgelegt auf die Unterstützung eines Vertriebs- 
Innendienstes, d.h. auf Arbeitsplätze in Büros. Für die Unterstützung des Außen- 
dienstes müssen wegen der großen Variabilität in der organisatorischen Ausgestal- 
tung meist Spezialsysteme beschafft oder selbst entwickelt werden. Beispiele solcher 
Systeme sind: 

o Tourenplanung 
o Mobile Auftragserfassung 
o Außendienstinformation. 

Zunehmend wichtiger wird gerade auch die letztgenannte Anwendung. Es kann 
für den Markterfolg mit entscheidend sein, dass ein Außendienstmitarbeiter vor Ort 
Zugriff auf zentrale Daten hat, insbesondere auch die Grunddaten Kunde. Die Da- 
tenquelle für CRM-Systeme ist zu einem hohen Anteil der Mitarbeiter vor Ort. Nur 
er hat detaillierte Informationen über den Kunden. 
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7.3.5 Projekte 

Projekte sind in den beiden Kapiteln 5 und 6 nicht direkt aufgetaucht, weil sie keine 
Routineprozesse sind. Ein Projekt ist ein länger dauernder Prozess aus Tätigkeiten 
vieler Akteure mit einem definierten Ziel, in dem unter anderem auch Vorgangsdaten 
entstehen oder entstehen sollten. Dies sind Aufzeichnungen über den Verlauf, wie 
bei Routineprozessen auch. Es unterscheidet sich vom Routineprozess durch einen 
sehr viel höheren Grad an Unhestlmmtheit und Risiko, da zwar das Ziel, nicht aber 
das konkrete Ergebnis ä priori fest stehen. Jedes Projekt für sich ist einmalig, was 
nicht ausschließt, dass sich einzelne Tätigkeiten gegenüber einem Vorgängerprojekt 
wiederholen. 

Beispiele für Projekte Im Industrieunternehmen wären eine Marketingkampagne, 
die Automatisierung von Versandanlagen oder die Installation eines Softwarepakets 
(sog. IT-Projekt). Projekte sind in der Regel personallntensiv. Menschen müssen sich 
koordinieren, wenn sie Tätigkeiten ausführen, die einen hohen Neuigkeitsgrad ha- 
ben. Zwischen den Tätigkeiten gibt es sachliche und zeitliche Abhängigkeiten. Dies 
macht die Methodik Netzplantechnik interessant (s. Müller-Merbach, 1992). Eür das 
Projekt müssen Anlagen und Dienstleistungen (sog. „Berater“) beschafft werden. Zu 
Beginn des Projektes ist ein Projektplan aufzustellen, der über die geschätzte Dau- 
er der Tätigkeiten, die Beschaffungspreise und eine Position Unvorhersehbares eine 
Aufwandschätzung für ein Budget und einen Terminplan enthält (s. hierzu Spitta, 
1993). 

Auf dieser Basis lassen sich Daten benennen, die eine Projektabwicklung braucht, 
und zwar (s. Tabelle 7.2): 

o ein Grundobjekttyp Projekt, denn es werden viele Projekte gleichzeitig abge- 
wickelt, Insbesondere IT-Projekte. 

o Anlagen und (Dienst-)Leistungen, die beschafft werden müssen. Solche 
Dienstleistungen werden zum Festpreis angeboten oder die Externen arbeiten 
nach Aufwand. 

o Mitarbeiter oder Dienstleister, die Leistungen erbringen. Diese 
beruhen auf einer Leistungserfassung von Arbeitszeiten und werden bei Externen 
nach geleisteter Arbeitszeit vergütet. 

o Eür große Projekte benötigt man Netzpläne, die eine Projektabwicklungskom- 
ponente unterstützen muss. „Groß“ heißt, dass viele Akteure und Objekte über 
einen längeren Zeitraum koordiniert werden müssen. Netzpläne haben eine Plan- 
und eine Istkomponente. Die Istdaten sind geeignet verdichtete Leistungsdaten, 
die den Planpositionen zugeordnet werden. 

Die wichtigsten Funktionen eines Anwendungssystems Projektabwicklung sind 
(s. auch Kurbel, 2005, Abschn. 5.7): 

o Aktivitätenplanung (mit Terminen, Kapazitäten und Ressourcen); Ergebnis ist 
eine Aufwandschätzung, 
o Grunddatenverwaltung 

o Erfassen von Vorgangsdaten (Leistungen), auch Zeiterfassung genannt, 
o Netzplanverwaltung 
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o Soll-Ist - Vergleich Kosten und Termine, sowie viele andere Auswertungen. 

Projekte sind nicht an bestimmte Funktionsbereiche gebunden. Sie haben jedoch 
auch einen Bezug zu scheinbaren Routineprozessen, die in Wirklichkeit keine sind. 
Die Herstellung großer Produkte (Schiffe, Gebäude, Infrastrukturen usw.) sind Pro- 
jekte. Die Abwicklung jedes Auftrages ist ein Projekt. In solchen Unternehmen wird 
regelmäßig auch mit Netzplänen gearbeitet. 

7.3.6 Personalsystem 

Ein Anwendungssystem Personal ist dasjenige, das sich ein Laie noch am ehes- 
ten intuitiv vorstellen kann. Das Unternehmen hat Mitarbeiter, also braucht man im 
gleichnamigen Grundobjekttyp einige Merkmale zur Person, Adressdaten und die 
Kontoverbindung. Außerdem muss monatlich das Gehalt gezahlt werden. Das trifft 
im Grundsatz auch zu, nicht aber im Detail. 

Neben der notwendigen Skalierung auf viele Mitarbeiter und Standorte kommt in 
der Branche Industrie als spezielles Problem der Leistungslohn hinzu. Vor allem in 
großen Unternehmen gibt es eine Vielzahl tarifabhängiger Löhne, für die passende 
Mengendaten erst gesammelt und bereit gestellt werden müssen. Allein ein Schicht- 
zuschlag verlangt Daten über Schichtpläne, wenn er richtig berechnet werden soll. 
Dies macht die sog. Bruttolohnabrechnung sehr komplex. Sie muss vor jeder Mo- 
natsabrechnung mit aktuellen Daten versorgt werden. 

Folgende Funktionen bilden den Kern eines Personalsystems, das wegen vieler 
gesetzlicher Vorgaben (Steuern, Sozialabgaben) eigentlich immer als Standardsoft- 
ware oder außer Haus bei einem Dienstleister (z.B. DATEV) betrieben wird: 

o Zeit- und Leistungsdaten 
o Bruttoabrechnung 
o Nettoabrechnung 

o Datentransfer (Krankenkassen, Rententräger, Banken) 
o Personalbetreuung 
o Nachweise. 

Die letzten beiden Punktionen laufen im Dialog ab, die ersten vier bilden zusam- 
men einen lang laufenden, monatlichen Batchprozess. 

7.3.7 Zwischenstatus als Überblick 

Bevor wir das sehr zentrale System Finanzbuchhaltung behandeln, ist ein Zwischen- 
status mit einem grafischen Überblick angebracht, den Abb. 7.3 bietet. Er zeigt die 
bisher behandelten Anwendungssysteme und die mit ihnen verknüpften Grund- und 
Bestandsdaten zuzüglich der gleich noch zu besprechenden „Buchhaltung Mit Vor- 
gangsdaten wäre das Bild unlesbar geworden. Die Kanten zwischen den beiden Kno- 
tentypen Aktion = Anwendungssystem und Objekt = Datenobjekttyp sind ungerichtet 
und geben nur eine nicht näher spezifizierte Assoziation an. 
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Abb. 7.3. Überblick Anwendungssysteme, Grund- und Bestandsdaten 



Man sieht die zentrale Bedeutung von Teil und /Bestand und die alleinige 
Beziehung der Buchhaltung zu /Konto. Logisch ist die Anlage auch eine Rolle 
von Tei 1 und sie benötigt auch Stücklisten (vgl. Abschnitt 5.4.1). Tatsächlich hat sie 
aber so verschiedene Attribute, dass sie getrennt definiert und gespeichert wird. Die 
Verbindungen zwischen Lieferant, Kunde und Buchhaltung sind die Rechnungsda- 
ten, diejenigen zwischen Materialwirtschaft, Personalsystem und Buchhaltung ver- 
dichtete Daten mit bewerteten Mengen (Vorräte) und Zahlungen an Mitarbeiter. Die 
Daten liefernden Systeme werden auch „Buchhaltungen“ genannt {Lager- und Per- 
sonalbuchhaltung). Deshalb ist der Begriff Finanzbuchhaltung klarer. 

Der Überblick dient dazu, ein Verständnis für die Datenintegration durch eine 
Finanzbuchhaltung vorzubereiten, die jetzt besprochen wird. Außerdem benutzen 
wir den folgenden Abschnitt, um am Beispiel der Finanzbuchhaltung die allgemeine 
funktionale Struktur von Anwendungssystemen zu zeigen, die die Pflege originärer 
Daten und das Erzeugen abgeleiteter Daten vereint. 

7.3.8 Finanzbuchhaltung 

Auf Grund der gesetzlichen Vorgaben für das externe Rechnungswesen verfügen 
heute fast alle, auch sehr kleine Unternehmen, über eine Standardsoftware mit ei- 
ner Finanzbuchhaltung als „Herzstück“. Warum dieser Begriff gewählt wird, deutet 
sich schon in Abb. 7.3 an: Alle Anwendungssysteme liefern Daten an die Buchhal- 
tung, die Grunddaten Kunde und Lieferant werden dort ln den Rollen Debitor 
und Kreditor benötigt, weil das Rechnungswesen alle Gläubiger- und Schuldner- 
Beziehungen direkt dokumentieren muss. 
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In Abschnitt 5.5.1 hatten wir Buchung als einzigen, wenn auch sehr vielfälti- 
gen Vorgangsobjekttyp der Buchhaltung ausgemacht, der in die maschinell erzeugten 
BuchungsPositionen (Soll/Haben) zerfällt. /Konto ist in verschiedenen Ausprägun- 
gen nach Maßgabe des Grundobjekttyps Kontenplan vorhanden. Üblicher Weise 
haben Unternehmen zwischen 100 und 200 konkrete Konten. 

Die Buchungen gelangen in einer Organisationseinheit Buchhaltung nur zum ge- 
ringeren Teil im Dialog in die Konten. Das Gros der verdichteten Buchungen wird 
maschinell aus den Anwendungssystemen Materialwirtschaft, Personal und Vertrieb 
in den Konten abgelegt. Dies sind, wie in Abb. 7.4 gezeigt, alle Rechnungen, Bestän- 
de und Entgeltzahlungen. 




/Warenausgang l 
/F akturlerung 

/■'Wareneingang 1 
'../RechnPrüfiing.-' 



Abb. 7.4. Die Finanzbuchhaltung als Datenverdichtungssystem (nach Alpar et al., 2002) 



Neben der Hauptbuchhaltung, in der im Dialog gebucht werden kann und die 
Funktionen zur Erzeugung abgeleiteter Daten enthält (z.B. Tages-, Monats-, Quartals- 
und Jahresabschluss) gibt es Nebenbuchhaltungen, die entweder im System Finanz- 
buchhaltung enthalten {Kontokorrentbuchhaltungen) oder nur Schnittstellen zu an- 
deren Anwendungssystemen sind. Die Systeme Anlagenbuchhaltung, Lohn- und Ge- 
haltsabrechnung und Lagerbestandsführung liefern verdichtete Daten an die Finanz- 
buchhaltung. Die aufzeichnungspflichtigen Originalvorgänge werden in den genann- 
ten Systemen archiviert. 











7.3 Funktionsbausteine 



123 



Eine wesentliche Eigenschaft einer Einanzbuchhaltung sind ihre Schnittstellen, 
die Abb. 7.4 in Eorm von synchronen Pfeilen zeigt. Entweder sammeln die vorge- 
lagerten Systeme Daten und buchen sie abends in die Buchhaltung oder es wird 
realtime als Transaktion gebucht. Diese Fähigkeit der SAP-Systeme R/2 und R/3 
(ab 1992) wurde offenbar vom Markt als sehr wertvoll eingeschätzt. Das ’R’ heißt 
realtime (s. Plattner, 1981). Ein Wareneingang in der Materialwirtschaft löst eine 
Zugangsbuchung auf einem Bestandskonto der Buchhaltung aus. /Bestand in der 
Materialwirtschaft und das entsprechende Konto sind also immer stimmig. 

Als Einschub ein Beispiel, das zeigt, was sich praktisch allein in einer Debito- 
renbuchhaltung abspielen kann. Es stammt von Mertens (2004, 250): 

„Der Kunde 

1 . zahlt mit einer Akontozahlung einen runden Betrag, 

2. addiert bei der Zusammenfassung mehrerer Rechnungen falsch, 

3. fasst mehrere Rechnungen in einer Zahlung zusammen, gibt aber die Nummern 
der Rechnungen nicht an, 

4. saldiert ohne Vermerke mit Gutschriften, 

5. trägt an Stelle der Rechnungsnummer die Bestellnummer ein, 

6. verrechnet sich bei der Ermittlung des Skontos, 

7. zieht unberechtigt Skonto ab.“ 

Man sieht, welch praktische Bedeutung, aber auch welche Grenzen Primär- 
schlüssel als Vorgangsnummern haben. Zwar ist die Eindeutigkeit eines Vorgangs 
sicher gestellt, aber auf der Ebene der Attribute gibt es viele Fehler, die der Benutzer 
verantwortet (mehr dazu in Kapitel 8). Vor allem aber ist erkennbar: 

Wenn wir versucht hätten, alles was real Vorkommen kann, zu modellieren 

oder zu berichten, wäre für den Leser wenig Orientierung übrig geblieben. 

In einer Finanzbuchhaltung werden bis auf die Dialogbuchungen überwiegend 
abgeleitete Daten gebucht, die das Anwendungssystem für die diversen Abschlüsse 
bis zu Bilanz mit GuV sammelt. Die Integration einer Finanzbuchhaltung ist eine 
Datenintegration. 

Die Finanzbuchhaltung muss eine einheitliche Sicht auf die Geschäftsvorfälle 
und das Vermögen eines Unternehmens erlauben. Die Einheitlichkeit stellt sie her, 
indem alle Mengen (Verbräuche, Absatzmengen) mit Preisen bewertet werden. Hier- 
durch haben alle Zahlenangaben der Buchhaltung eine einheitliche Dimension, sind 
also kummulierbar. Dies ist bei Mengen nicht der Fall. Verbrauchte [Liter] und pro- 
duzierte [Stück] kann man nicht aggregieren. Damit ist die Finanzbuchhaltung, ge- 
nutzt vom Rechnungswesen, ein einheitliches, wertbezogenes Informationssystem 
des Unternehmens. Es kann jedoch keine mengenbezogenen oder detaillierten Infor- 
mationen aus den originären Daten liefern, die sich etwa auf Produkte oder Mitarbei- 
ter beziehen. Solche Informationssysteme sind in den entsprechenden Anwendungs- 
systemen angesiedelt oder als System Controlling separat ausgewiesen (s. Tabelle 
7.2). 

Auch die bisher nicht genannte Kostenrechnung kann nur die Informationen lie- 
fern, die in den operativen Systemen verfügbar sind (Schwarz, 2002). Sie zeigt be- 




124 7 Anwendungssysteme 



wertete Vorgänge, etwa Lohn- und Materialkosten, bewertete Grunddaten wie et- 
wa kalkulatorische Raumkosten und viele andere mit Preisen bewertete Mengengrö- 
ßen. Sie erzeugt fast nur abgeleitete Daten, etwa eine Glättung der Lohnnebenkosten 
(z.B. Weihnachtsgeld) über die Monate eines Berichtszeitraumes. Allerdings wird je- 
de Controlling- Abteilung ihre Informationsbedürfnisse auch in Grunddaten ablegen, 
vor allem in Kategorien, nach denen Daten klassifiziert werden, oder in Parametern 
für gewünschte Berechnungen. Ebenso wird sie originäre Plandaten selbst pflegen. 
Sie wertet die Daten der Finanz-, Material- oder Lohnbuchhaltung aus, die nach Kos- 
tenarten vorliegen und nach der Kategorie Kostenstelle gezeigt oder verdichtet wer- 
den. Eine Kostenträgerrechnung benötigt in aller Regel eine Materialwirtschaft, da 
nur sie über die erforderlichen produktbezogen Daten verfügt. 

Aus Abb. 7.4 kann man auch in der Untergliederung der Hauptbuchhaltung die 
allgemeine Struktur von Anwendungssystemen, übersetzt in unser Begriffssystem, 
ablesen: 

o Grunddatenpflege 
o Buchungen (Vorgänge) 
o Information im Dialog 
o Information per Batchabruf 
o Plandaten. 

Zusammenfassung Abschnitt 7.3 

1. Materialwirtschaft 

o Die Materialwirtschaft legt als Daten den GOT Teil und den BOT /Be- 
stand mit den Vorgängen zur Materialbewegung zu Grunde. 

o Sie ist eine integrierende Kernanwendung des Unternehmens. 

o Je differenzierter die Rollen von Teil und die Struktur physischer Läger 
sind, desto komplexer wird die Bestandsführung. 

o Optimierungen oder detaillierte Informationen aus der Materialwirtschaft 
kann man nur mit entsprechend differenzierten Daten erhalten. 

2. Einkauf 

o Ein Einkaufssystem ist sehr eng mit einer Materialwirtschaft verknüpft. 

o In diesem System sind einige Optimierungsfunktionen angesiedelt, die übli- 
cher Weise in der Betriebswirtschaftslehre behandelt werden (z.B. Losgrö- 
ßen, Bestellzeitpunkte). 

o Neben der Abwicklung von Bestellungen sollte es eine Funktion zur Analyse 
von Daten des Beschaffungsmarktes geben. 

3. PPS-System 

o PPS-Systeme sind schlechter standardisierbar als andere Anwendungssyste- 
me. 

o Ihr Haupt-Einsatzgebiet ist die Fertigung kleiner und mittelgroßer Serien. 

o Eine Steuerung ist nur möglich, wenn zeitnah und detailliert Istdaten erfasst 
werden. 

o Die Grunddaten müssen strukturell zur Art der Fertigung passen. 
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o Auch ein PPS-System benötigt die Lager-Komponente. 

4. Vertrieb 

o Ein Vertriebssystem unterstützt den Prozess Auftragsabwicklung entspre- 
chend den nacheinander auszuführenden Funktionen. 

o Darüber hinaus unterstützt es heute den dazu vorbereitenden Prozess durch 
Produktpräsentation im Internet. 

o Funktionen zur Unterstützung des Außendienstes sind meist nur in Zusatz- 
paketen enthalten. Dabei spielt ein online-Zugang zu zentralen Kundendaten 
eine zunehmend wichtigere Rolle. 

5. Projektsystem 

o Projekte sind komplexe Vorhaben über längere Zeiträume, die im Gegensatz 
zu Routineprozessen nicht repetitiv, sondern einmalig sind. 

o Die Einzelfertigung großer Produkte benötigt ein Anwendungssystem Pro- 
jektabwicklung. 

6. Personalsystem 

o Die Personalabrechnung ist einer der wenigen für den Anwender nachvoll- 
ziehbaren Prozesse, der im Batchbetrieb abläuft. 

o Die Lohnabrechnung ist in der Branche Industrie besonders komplex. 

o In diesem System findet ein automatisierter Datentransfer über Protokolle 
mit externen Akteuren schon sehr lange statt. 

7. Buchhaltung 

o Das zentrale Anwendungssystem zur Integration der Unternehmensdaten ist 
die Finanzbuchhaltung. 

o Sie zeigt alle wichtigen Werte und externen Geschäftsvorfälle, aber keine 
Detailinformationen über Mengen. 

o Die Finanzbuchhaltung ist auf Datenlieferungen der operativen Systeme Ma- 
terialwirtschaft, Vertrieb, PPS und Personal angewiesen. Sie integriert die 
Daten der zuliefernden Systeme auf Wertebene. 

o Die Kostenrechnung ist ein Informationssystem, das sich überwiegend aus 
den Vorgangsdaten der operativen Systeme speist. Es zeigt bewertete Men- 
gen. 



7.4 Wiederholung 

• Betriebliche Anwendungssysteme sind Softwaresysteme, die im Dialog betrieben 
werden und ergänzend über Batchfunktionen verfügen. 

• Der größere Teil der originären betrieblichen Daten wird von Menschen festge- 
legt und im Dialog in die Datenbasis eingegeben. 

• Die Korrektheit der originären Daten ist von sorgfältig definierten und implemen- 
tierten Integritätsbedingungen abhängig. Dies muss die Benutzerschnittstelle der 
Anwendungssysteme bestimmten. 

• Falsche originäre Daten können betriebliche Abläufe empfindlich stören. 

• Die Anwendungssysteme des Leistungsbereiches werden vor allem von den GOT 
Teil und dem BOT /Bestand bestimmt. 
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• Der Finanzbereich integriert alle aufzeichnungspflichtigen Geschäftsvorfälle, in 
verdichteter Form auch die aus den Anwendungssystemen des Leistungsbe- 
reichs. Dessen Systeme spielen aus Sicht der Finanzbuchhaltung die Rolle von 
Nebenbuchhaltungen. 
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Datenverantwortung und Organisation 



In Abschnitt 5.1 hatten wir als Erkennungskriterium für originäre Daten den Men- 
schen als Datenursprung benannt. Ebenso war zu Beginn des vorigen Kapitels der 
Mensch als Aufgabenträger bei der Erzeugung betrieblicher Daten für Anwendungs- 
systeme betrachtet worden. Auch seine Einbindung in eine Organisation war kurz 
angeklungen. Dies soll in einem separaten Kapitel vertieft werden. Das erscheint 
unter anderem deshalb wichtig, weil sehr viele Leser Vorerfahrungen mit einem Per- 
ionaZ-Computer haben. Der individuelle Benutzer ist für das hier angemessene Bild, 
den kooperativen Benutzer, genau die falsche Metapher. Als kooperativ bezeichnet 
man die Mitglieder einer zielgerichteten Organisation, wie ein Unternehmen sie dar- 
stellt. Was das für die betriebliche Informationswirtschaft bedeutet, soll in diesem 
Kapitel geklärt werden. 



8.1 Benutzer und Datenverantwortung 

Schon in Abschnitt 7.1 war das Problem der Korrektheit der durch den Benutzer er- 
zeugten Daten angesprochen worden. Können über Integritätsbedingungen alle Da- 
ten als korrekt verihziert werden? Wie man am Beispiel von Tabelle 8.1 sieht, ist das 
nicht der Eall. 



Tabelle 8.1. Dateneingabe durch einen Benutzer 



Eingabe 


(Lager-)Bewegi 

(LagerNr#, 


ung 

ArtikelNr# , 


Datum, 


Zeit, 


Menge) 


Meldung 


1 . Versuch 


121 


4816 






-20 


Falsches Lager 


2. Versuch 


122 


4816 






-20 


gebucht 



Die Attribute LagerNr und ArtikelNr seien als Aufzählungstypen wie folgt 
dehniert: Lagernr= {122,123,640,701} (vgl. Tabelle 5.8), ArtikelNr= 
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integer; 1000 . .9999 (vgl. Tabelle 3.10). Aufzählungstypen sind einfache In- 
tegritätsbedingungen, die das Abspeichern nicht definierter Werte verhindern (s. „1. 
Versuch“). Nach demselben Prinzip könnte man die Artikelnummern 481 oder 816 
(eine Stelle zu wenig) abweisen. Bucht der Benutzer jedoch vom Bestand des Arti- 
kels 4816 ah, obwohl 4826 richtig gewesen wäre, kann dies kein Computer verhin- 
dern.^ Der Benutzer verantwortet diesen Fehler selbst. 

Im Übrigen kann er bei Datum und Uhr zeit keine Fehler machen, da die Wer- 
te sinnvoller Weise durch das Programm eingesetzt werden, mittels dessen er die 
Daten eingibt. 

Dies bedeutet für die Organisation, in die der Benutzer eingebunden ist: 

1. Solche Fehler können Vorkommen, denn Irren ist bekanntlich menschlich. In 
stressigen Arbeitssituationen wird die Wahrscheinlichkeit für solche Fehler grö- 
ßer sein als in einem „Normalbetrieb“. Das Unternehmen muss also prinzipiell 
mit solchen Fehlern rechnen. 

2. Es müssen diejenigen Mitarbeiter eingesetzt werden, die möglichst wenige Feh- 
ler machen. Dies verantwortet die Organisationseinheit, deren Aufgabe die Er- 
zeugung der Daten ist. Der Mitarbeiter verantwortet aber seine Eehler persönlich 
gegenüber seiner Organisationseinheit, ist also gut beraten, genügend Sorgfalt zu 
entwickeln. 

Für die Informationswirtschaft des Unternehmens bedeutet dies, dass für die 
jeweiligen Datenobjekttypen Verantwortlichkeiten festgelegt und möglichst auch 
durchgesetzt werden müssen. In der betriebswirtschaftlichen Literatur konnten für 
dieses Thema keine Hinweise gefunden werden (vgl. z.B. Schreyögg & von Werder, 
2004; dort inbes. Erank, 2004). In amerikanischen Büchern wie Boland & Hirsch- 
heim (1991, viii) findet man immerhin Bemerkungen, dass die organisatorischen 
Auswirkungen der Informationstechnik vernachlässigt werden. Mehr wurde aller- 
dings auch nicht gefunden. Ein bekanntes Buch über modulare Organisationsformen 
mittels der Informationstechnik (auch in den USA erschienen) stammt von Picot 
et al. (2001). Es behandelt das Thema Daten und deren organisatorische Veranke- 
rung allerdings auch nicht, obwohl die Erage der Grenzziehung zwischen Modulen 
und deren Schnittstellen viel mit Datenverantwortung zu tun hat. Spitta (1997) und 
ein Arbeitspapier von 1998 (s. Spitta, 2005) führen dazu einige Gedanken an Hand 
der Eallstudie eines modularen Unternehmens aus. 



* Praktisch versierte Leser werden das Stichwort Prüfziffer in die Arena der Diskussion wer- 
fen. Darüber kann in Stahlknecht & Hasenkamp (2005, 142) nachgelesen werden. Der 
Autor hat jedoch Zweifel an der Verbreitung dieser simplen Variante angewandter Mathe- 
matik - nicht Technik -, da nicht einmal Hochschulen bekannt zu sein scheint, wie sie ihre 
Matrikelnummern gegen solche Tippfehler schützen können. 
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8.2 Zugriffsrechte als Pflichten 

Dem Leser wird einsichtig sein, dass Maßhalteappelle der Art „passt alle gut auf“ 
nicht viel helfen. Es gibt allerdings technische Mittel, die außerordentlich wirksam 
sind, organisatorisch Gewolltes auch durchzusetzen. 

Jedes Anwendungssystem und jede Mehrbenutzer-Datenbank verfügt über eine 
Komponente Benutzerverwaltung. In ihr wird festgelegt, welche Benutzer welche 
Operationen mit welchen Datenobjekttypen bzw. Tabellen ausführen dürfen. Man 
erteilt den Benutzern Zugriffsrechte, die man für jeden Typ von Operation je Benut- 
zer festlegen kann. Diese Operationen, bezogen auf ein einzelnes Objekt (etwa einen 
Artikel) sind: 

o anlegen 
o ändern 
o löschen 
o lesen. 

Nur die ersten drei Operationen können Daten verändern. Da Benutzer in ei- 
nem kooperativen Computersystem nur persönliche^ Rechte zum Zugriff auf Daten 
erhalten, kann bis auf die Person hinunter festgelegt werden, welche Daten sie wie 
bearbeiten oder überhaupt sehen darf. Dies enthebt aber die Organisationseinheit, der 
die Person angehört, nicht ihrer Verantwortung für die Korrektheit und rechtzeitige 
Eingabe der Daten. Kooperativ war das Computersystem genannt worden, weil in ei- 
nem Unternehmen viele Menschen zielgerichtet zusammen arbeiten (sollten), wenn 
es erfolgreich sein will. 

Ohne explizite Leserechte sind Daten für den Benutzer unsichtbar.^ Dies ist eine 
von vielen Maßnahmen, um Datenschutz technisch zu verwirklichen. 

Ob die Benutzerverwaltung die Zuweisung der Rechte auf der Ebene von Da- 
tenbanktabellen regelt oder über das Recht, die Programme zu benutzen, die die 
Daten verwalten, ist für unser Thema unerheblich. Gute Systeme sehen zwecks Ar- 
beitsvereinfachung Gruppen von Zugriffsrechten vor, in die ein Benutzer nur auf- 
genommen oder aus ihr entfernt wird. Da fast jedes Unternehmen heute Standard- 
Anwendungssysteme betreibt, die große Mehrzahl inzwischen auf der Basis von 
Datenbanken, sind die technischen Mittel zur Durchsetzung von Datenverantwort- 
lichkeiten vorhanden. Woran es eher zu fehlen scheint, ist das Bewusstsein um den 
Nutzen solcher Systeme in den Unternehmen. 

Wenn ein Daten veränderndes Benutzungsrecht technisch zugewiesen ist, ist da- 
mit auch die Verantwortung für die Ergebnisse klar. Damit wird aber auch die Pflicht 
begründet, die Inhalte der erzeugten Daten zu verantworten. Der nächste Abschnitt 
gibt dazu Gestaltungshinweise. 



^ Dies hängt mit vielfältigen Bedrohungen, u.a. aus dem Internet zusammen, ist aber nicht 
unser Thema. 

^ Dies gilt zumindest seit rund 20 Jahren als wichtiges Prinzip. Leider wird es von weit 
verbreiteten Produkten verletzt. 
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8.3 Gestaltungshinweise 

Aus den Kapiteln 5 und 6 kennen wir die Abhängigkeiten der Vorgangsdaten von den 
Grunddaten. Dies allein genügt schon als Hinweis, dass die beiden Datenkategorien 
verschiedene Gewichte bei der Regelung der Datenverantwortung haben. 

Wenn im Folgenden ohne nähere Erklärung von (Organisations-)£'/M/ietY gespro- 
chen wird, dabei aber Namen von Funktionen erscheinen (s. Kapitel 2), dann soll 
dies nicht etwa bedeuten, dass nur funktional zu organisieren wäre. Funktionsnamen 
im Kontext dieses Kapitels haben vielmehr die Bedeutung: 

Einheit bzw. Bereich ist diejenige Organisationseinheit, zu deren Aufgaben 
die genannte Funktion gehört. 

8.3.1 Pflege von Grunddaten 

Die Regelung der Datenverantwortung ist bei den Grunddaten schwieriger als bei 
den Vorgangsdaten, die den Routinebetrieb prägen. Unter ihnen spielt wiederum der 
GOT Teil eine herausragende Rolle. 

Grundaten Teil 

Der Prozess der Entstehung der Grunddaten zu Tei 1 ist identisch mit dem uns schon 
bekannten Prozess Produktentwicklung (s. Abb. 2.6, Seite 16). Dort sind verschiede- 
ne Akteure in Aktivitätsbereichen angeordnet: Entwicklungsausschuss, Entwicklung, 
Produktion, Geschäftsleitung. Weitere Beteiligte sind als Mitglieder des Entwick- 
lungsausschusses in der Abbildung genannt. Es gibt also keine eindeutig identifizier- 
bare Organisationseinheit, der die Datenverantwortung zuzuschreiben wäre. 

Auch die Rollenhierarchie von Teil in Abb. 5.4, Seite 63 zeigt, dass zumindest 
die betrieblichen Funktionen Beschaffung, Produktion und Absatz mit Ausschnitten 
aus den Attributen des GOT Teil befasst sind. Tabelle 8.2 zeigt dieses Gefüge von 
Rollen und Funktionen noch einmal schematisch, ’x’ bedeutet, dass Daten erzeugt 
werden, ’(x)’ dass Daten entstehen können. Dies wäre z.B. der Fall, wenn die Ent- 
wicklung beim Zukauf von Produkten konkurrierende Entwürfe machte, denen eine 
Entscheidung make-or-buy folgt. 



Tabelle 8.2. Datenentstehung von Attributen des GOT Teil 



Funktion 

Rolle 


Produktion Absatz Beschaffung 

Entwicklung Prod-Planung Marketing Besch-Planung 


VerkaufsTeil 


(X) 


(X) 


X X 


ProduktionsTeil 


X 


X 


X 


EinkaufsTeil 


X 




X 



Bis etwa 1990 war in vielen Industrieunternehmen das vorliegende Entschei- 
dungsproblem vermeintlich klar. Der Bereich Produktion definierte die meisten Tei- 
ledaten bei der Konstruktion und der Produktionsplanung. Meist wurde die Einheit 
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Entwicklung mit der Pflege der gesamten Grunddaten beauftragt, da dort jedes neue 
Teil auch entstand. Mit dem Aufkommen einer marktorientierten Unternehmensfüh- 
rung (vgl. Decker, 2005; Töpfer, 2005) gingen viele Unternehmen dazu über, diese 
Verantwortung dem Absatzbereich zu übertragen, dort einer Einheit Marketing, wo 
viele Produktideen entstehen. Es sind eine Reihe von Fällen bekannt, wo dies zu 
massiven logistischen Störungen führte, weil Produktdaten fehlerhaft oder gar nicht 
angelegt waren. Ursache war vermutlich der geringe Bezug von Mitarbeitern des 
Absatzbereiches zu den eher technischen Fragen von Produktstrukturen. 

In dem in Kapitel 1 erwähnten Fall eines Massenherstellers führten trotz hoher De- 
ckungsbeiträge der Produkte und eines sehr großen Marktanteils logistische Störun- 
gen zu Verlusten, sogar über mehrere Jahre. Viele Störungen hatten ihre Ursache in 
einer mangelhaften Definition und Pflege der Artikel Stammdaten. Erst deren Reorga- 
nisation im Rahmen einer Erneuerung der Pflegesoftware beendete diesen Zustand. 

Vor der Einführung der Software mussten die Artikeldaten eineinhalb Jahre lang 
saniert werden, indem fehlerhafte Kategorien (vgl. Abschnitt 5.4.2) aufgespürt und 
beseitigt wurden. Das war bei 650.000 Bestandspositionen (= Artikelvarianten) ein 
mühsames Unterfangen. 

Die Matrix in Tabelle 8.2 und der Prozess Produktentwicklung zeigen zwei grundle- 
gende Phänomene bei der Entstehung von Grunddaten: 

o Die Daten komplexer Grundobjekttypen entstehen nicht nur in einer betriebli- 
chen Funktion, sondern in mehreren. Benötigt wird aber eine eindeutige Verant- 
wortung. Manche Attribute sind rollenspezifisch, 
o Viele Attribute entstehen in einem Prozess mit möglicher Parallelarbeit, andere 
zwingend in einer Sequenz. So kann man nicht kalkulieren, so lange Stücklisten 
und Einkaufspreise fehlen. 

Daraus ergibt sich, dass keine Objektverantwortung (hier GOT Teil) gebraucht 
wird, sondern eine Prozessverantwortung mit entsprechenden Kompetenzen. Schwer- 
punktmäßig sollte diese Verantwortung in den Funktionen Marketing oder Entwick- 
lung liegen, es könnte aber auch eine Querschnittfunktion Logistik sein. Mit dem 
Konfliktpotential jeder dieser Zuordnungen müssen Unternehmen umgehen lernen. 
Die Objektverantwortung ist gemäß Abb. 8.1 aufgeteilt auf mehrere Funktionen bzw. 
Einheiten. 

Für einen Prozess, wie Abb. 8.1 ihn zeigt, könnte man einen Begriff heranzie- 
hen, der leider zum Modeschlagwort verkommen ist, Workflow. Das deutsche Wort 
Arbeitsablauf trifft den Sachverhalt nicht ganz und ist nicht üblich. Als Workflow 
bezeichnet man einen innerbetrieblichen Prozess, bei dem Daten über die Grenzen 
von Organisationseinheiten hinweg arbeitsteilig und technikgestützt entstehen. Man 
kann z.B. mit dem Ereignis „Daten fertig gestellt“ bei Bearbeiter n das automatische 
Versenden einer Mail an Bearbeiter n+1 koppeln, damit dieser die Arbeit fortsetzt. 
Die Diskussion um Workflow-Systeme wird allerdings allzu oft technikorientiert ge- 
führt. Die kollaborative Entstehung der Grunddaten Teil dürfte einer der wenigen 
Fälle sein, bei denen Technik-Unterstützung eines Arbeitsprozesses angebracht ist. 
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I 

Entwicklung ^ 

1 



^ Beschaffung^ ^Prod-Planung^ 



^ Marketing ^ 

V 

^ Controlling ^ 



Abb. 8.1. Workflow bei der Erzeugung der Grunddaten Teil 



Deshalb ist sie in guten Anwendungssystemen seit den 80er Jahren enthalten,^ ohne 
dass jemand von „Workflow“ gesprochen hätte. 

Es bleibt noch die Umsetzung der organisatorischen Überlegungen in konkrete 
Zugriffsrechte. Dabei sollte das folgende Prinzip gelten: 

Datenverantwortung ist nicht teilbar. 

Dies bedeutet für die Pflege der Grunddaten Teil, dass genau eine Einheit die 
Prozessverantwortung und damit das alleinige Recht für die Operationen anlegen 
und löschen von Artikeln und Materialien hat. Die objektverantwortlichen Einheiten 
ergänzen die angelegten Objekte um die Attribute ihres Verantwortungsbereiches 
(Operation ändern) (s. auch Spitta, 1989, Kap. 6). Das Controlling würde am Schluss 
der Kette die Erzeugniskalkulation erstellen, auf deren Basis ggf. noch einmal über 
den Verkaufspreis zu entscheiden wäre. 

Datenverantwortlichkeiten müssen also bis auf das Attribut genau einer Ein- 
heit zugewiesen werden. Konkurrierende Datenverantwortlichkeiten sind gerade bei 
Grunddaten kontraproduktiv. Selbstverständlich muss es innerhalb der Einheiten 
Vertretungsregelungen geben. 

Die übrigen Grunddaten 

Mit Teil haben wir den schwierigsten Eall abgehandelt, der auch viele allgemeine 
Aspekte beleuchtet. Deshalb können wir uns bei den restlichen Grunddaten kurz 
fassen. 

^ Beispiel ist das längst untergegangene System COPICS (Communication Oriented Produc- 
tion Information and Control System) der Firma IBM. 
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Die Grunddaten der Kunden haben einen eindeutigen funktionalen Bezug. Die 
Datenverantwortung liegt beim Absatzbereich. Der Finanzbereich wird debitorische 
Attribute ergänzen, etwa Klassifikationen über das Zahlungsverhalten oder die Kre- 
ditwürdigkeit. Es kann sinnvoll sein, den Außendienst in die Grunddatenpflege mit 
einzubeziehen (vgl. Abschnitt 7.3.4, AWS Vertrieb). Dies muss aber technisch und 
organisatorisch (z.B. Schulungen) sehr sorgfältig implementiert werden. 

Die Grunddaten der Lieferanten sind fast spiegelbildlich zu Kunde zu sehen, 
d.h. die Datenpflege obliegt der Beschaffung, die Kreditorenbuchhaltung ergänzt At- 
tribute. Einen Außendienst gibt es nicht. 

Die Grunddaten der Mitarbeiter sind ebenfalls funktional klar, und zwar dem 
Personalbereich zugeordnet. Dabei muss man allerdings beachten, dass die Perso- 
nalfunktion in zwei Teilfunktionen zerfällt, die sehr verschiedene Mentalitäten der 
Mitarbeiter und damit Haltungen zum Thema Datenpflege beinhalten. Die Teilfunk- 
tionen könnte man Personalbetreuung und Personalabrechnung nennen. In der ersten 
entstehen Daten um den Mitarbeiter als Person (Familienstand, Kinder, Qualifikati- 
on, Weiterbildung ect.) in der zweiten sind alle abrechnungsrelevanten Daten zu pfle- 
gen. Diese Einheit heißt nicht selten Lohnbuchhaltung (s. auch Abschnitt 7.3.6). Hier 
ist Buchhaltermentalität gefragt, die ein exaktes Umgehen mit Daten erfordert. Man 
wird die Attribute des Grundobjekttyps Mitarbeiter in diese beiden Gruppen 
teilen und die Datenverantwortung entsprechend zuweisen. 

Die Grunddaten zu Sachanlagen, Kontenplan sowie alle Kategorien und Struk- 
turen (z.B. Konto - Bilanzposition), die die Buchhaltung betreffen, werden vom 
Bereich Finanzen gepflegt. Es ist implizit in realen Unternehmen unstrittig, dass 
das Rechnungswesen bestimmte Daten in seiner fachlichen Kompetenz auch selbst 
pflegt. Beachtet werden muss, dass gemäß GoB die Operation löschen nicht zuge- 
wiesen werden darf. Statt dessen muss es eine Operation stornieren geben, die aus 
der Transaktion "buchen mit inversem Betrag + neu buchen" besteht. 

Durchaus strittig sein kann allerdings die Pflege anderer Kategorien. In Ab- 
schnitt 7.3.8 hatten wir die Pflege von Kategorien der Kostenrechnung dem Con- 
trolling zugewiesen. Es ist möglich, dies so zu regeln, aber durchaus auch üblich, 
dass das Controlling nur Informationsbedürfnisse formuliert und die Datenverant- 
wortlichen der Eachfunktionen diese umsetzen. Aus Kapitel 6 wissen wir, dass viele 
Kategorien nur Attribute sind und damit genau einem Objekttyp zugeordnet werden 
(Normalformen). Eine Ausnahme bilden Kategorien, die Teil eines zusammenge- 
setzten Primärschlüssels sind (s. Beispiel /Bestand in Abschnitt 7.3.1, Seite 114). 
Diese werden jedoch meist bei der Installation eines Softwaresystems gesetzt, z.B. 
die Kategorien Mandant, Werk, Buchungskreis (vgl. Tabelle 5.9). 

8.3.2 Erzeugung von Vorgangsdaten 

Die Verantwortung bei Vorgangsdaten ist wesentlich unproblematischer als bei Grund- 
daten. Das liegt an ihrer Bindung an Routineprozesse, die wir aus Kapitel 2 kennen. 
Da Vorgänge durch Daten protokolliert werden, besteht die Arbeitsaufgabe des Mit- 
arbeiters im Routinebetrieb unter Anderem aus dem Erzeugen von Daten (nicht pfle- 
gen wie bei den Grunddaten!). Beispiele sind: 




134 8 Datenverantwortung und Organisation 



o Auftragserfassung 
o Bestellbearbeitung 

o Kommissionierung (Ausliefern eines Auftrages, dabei Erzeugen eines Liefer- 
scheines) 

o Produktion (erstellen von Leistungsnachweisen und buchen von Zustandsände- 
rungen in Produktionsaufträgen). 

Auch hier besteht eine klare Kopplung zwischen Datenerzeugung und Daten- 
verantwortung. Jeder operativ tätige Mitarbeiter hat das technische Recht anlegen 
von Datenobjekten. Die Operationen ändern und löschen werden gemäß GoB in den 
meisten Lällen nicht zugelassen sein {Storno-Prinzip). 

Damit wäre die Datenverantwortung heim Erzeugen der originären Daten be- 
sprochen. Die problematischen Bereiche sind die Grunddaten, da ihre Erzeugung 
und Pflege nicht in Routineprozesse eingebunden ist. 

Zusammenfassung Abschnitt 8.3 

o Der Benutzer verantwortet individuell die Korrektheit der von ihm er- 
zeugten Daten innerhalb der Regeln, die die Integritätsbedingungen 
technisch durchsetzen. 

o Besondere Beachtung muss der Prozess der Erzeugung der Grunddaten 
Teil genießen. 

o Datenverantwortung wird individuell technisch zugewiesen, muss aber 
institutionell in der Organisation getragen werden. 

o Die Datenerzeugung folgt vor allem beim GOT Teil einem Prozess, 
der eine einheitliche Prozessverantwortung und eine verteilte Objekt- 
verantwortung erfordert. 

o Bei Vorgangsdaten fällt die Datenverantwortung mit den zugewiesenen 
Routineaufgaben zusammen. 

o Bei aufzeichnungspflichtigen Vorgängen ist die Operation löschen nicht 
erlaubt. Statt dessen gilt das Storno-Prinzip. 



8.4 SQL und abgeleitete Daten 

Dieses Buch soll sich nicht mit Programmieren befassen (s. Vorwort). Trotzdem 
musste bereits einmal von dieser Eingrenzung abgewichen werden, als die Entste- 
hung abgeleiteter Daten erklärt werden sollte. Es musste wenigstens angedeutet wer- 
den (s. Seite 57), was Programmieren in etwa ist. Hier haben wir den zweiten Lall 
einer Abweichung vom Prinzip. Da es keine Datenverantwortung für abgeleitete Da- 
ten gibt, sondern nur eine Programmverantwortung, sollte der Leser wenigstens eine 
Vorstellung davon bekommen, was dies sein könnte und wo mögliche Schwierig- 
keiten liegen, wenn man abgeleitete Daten erzeugt. Als Beispiel benutzen wir die 
Sprache SQL, die scheinbar sehr einfach ist, aber ebenso wie die in Abb. 5.2 ge- 
zeigte Tabellenkalkulation viele Eehlermöglichkeiten in sich birgt, die erst auf den 
zweiten Blick sichtbar werden. 
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SQL setzt auf dem relationalen Modell auf, d.h. man fragt relationale Tabellen ab 
und erhält Mengen als Ergebnisse und nicht einzelnen Exemplare wie in konventio- 
nellen Programmiersprachen (COBOL, Pascal, Java). Also muss man die Tabellen- 
strukturen kennen und die Verknüpfung der Tabellen verstehen, um richtig abfragen 
zu können. Zunächst ein sehr einfaches Beispiel mit nur einer Tabelle (Hansen & 
Neumann, 2005, Bd.2, 449): 

select InventarNr , Titel 
from Buch 

where Preis < 19.99; 

Dies sieht so banal aus, dass man die Tabelle, aus der alle Bücher unter „19,99“ 
selektiert werden, fast nicht hinschreiben möchte: 

Buch ( InventarNr# , Titel, Verlag, Preis, Erscheinungsort) 

Trotzdem muss man den Tabellen- und die Attributnamen kennen, die man haben 
möchte und auch den Namen und Datentyp des Selektionskriteriums (Preis). Das 
Ergebnis der Selektion ist eine Menge in Eorm einer zweispaltigen Tabelle, die keine, 
eine oder viele Zeilen enthalten kann. 

Trotzdem gibt es bereits hier eine Fehlermöglichkeit. Wer den feinen, aber ge- 
wichtigen Unterschied zwischen ’<’ und ’<’ nicht kennt oder übersieht, bekommt je 
nach Preispolitik der Verlage ein völlig falsches Ergebnis, wenn er auch die Bücher 
mit Preis = 19.99 erfragen wollte. 

Ein zweites Beispiel soll folgende abgeleiteten Daten erzeugen: 

Die Mengen der von den Kunden im laufenden Jahr gekauften Artikel. 

Um dies mit SQL formulieren zu können, muss man eine Vorstellung von den Rela- 
tionen haben, in denen die originären Daten gespeichert sind. Dazu wiederholen wir 
die bereits aus Abb. 3.1, 5.1 1 und 6.2 bekannten Relationen zu einem Kundenauftrag. 

Auftrag ( Auf tragsNr# , KundenNr#, EingangsDat, Lieferdat) 
AuftragsPos ( Auf tragsNr# , ArtikelNr# , Menge) 

Daraus lässt sich folgende SQL- Abfrage formulieren: 

select KundenNr , ArtikelNr, sum(Menge) 
from Auftrag, AuftragsPos 

where Auf trag. Auf tragsNr = Auf tragsPos .Auf tragsNr 
and Auf trag . EingangsDat > '01.01.2005' 
group hy KundenNr , ArtikelNr; 

die folgende Ergebnisrelation liefert: 

/Ahsatz_Kunde (KundenNr, ArtikelNr, Menge). 

Man erhält also die summierten Mengen je Artikel, diese wiederum gruppiert je Kun- 
de. Die Tabelle wird sehr wahrscheinlich viele Ergebniszeilen enthalten. Formal wäre 
auch eine leere Treffermenge möglich, aber dann hätte die Firma überhaupt nichts 
verkauft und das wüsste jeder Mitarbeiter auch ohne Datenbankabfrage. 
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Aus der SQL-Abfrage kann man ablesen, dass beide Tabellen der Komposition 
Auftrag durchsucht werden, erst Auftrag, dann Auf tragsPos. Dahei werden die 
Mengen aller Artikelpositionen summiert, die zu demselben Auftrag gehören. Eine 
Gruppierung erfolgt erst nach der KundenNr, dann der ArtikelNr. Man muss auch 
wissen, dass man ohne Gruppierung gar nicht sinnvoll summieren könnte. Bei der 
Selektion werden nur Aufträge ab dem 2.1.2005 berücksichtigt. 

Die beiden Beispiele zeigen folgende allgemeinen Punkte für die Frage nach 
programmieren und Programmverantwortung'. 

o Die Sprache SQL ist offenbar sehr mächtig (s. Fanny & Taudes, 2000), da wir 
nicht im Programm formulieren, wie das Programm arbeiten soll, sondern nur, 
was wir als Ergebnis erwarten. 

o Trotzdem ist auch dies noch sehr formal und weit entfernt von der eigentlichen 
Frage, die der Benutzer gestellt hat. 

o Durch die Mengenorientierung von SQL kommt schnell ein Ergebnis zu Stande 
(s. vor allem das erste Beispiel). Viel wichtiger als das reine Ergebnis ist jedoch 
die Frage, ob es korrekt ist. 

Dies soll genügen, um dem Leser einen Eindruck zu vermitteln, was Programm- 
verantwortung in etwa bedeuten könnte. Damit soll vor allem dem Glauben entgegen 
gewirkt werden, „programmieren“ sei, den Computer zu einer Handlung zu bewe- 
gen. Verantwortlich programmieren heißt vielmehr, die Korrektheit der Ergebnisse 
sicherzustellen. 

Zusammenfassung Abschnitt 8.4 

o SQL ist eine sehr mächtige Sprache. Man kann sie aber nur richtig be- 
nutzen, wenn man die Mengenorientierung des Relationenmodells ver- 
standen hat. 

o Die Mengenorientierung sorgt schnell für Ergebnisse. Es kommt jedoch 
darauf an zu beurteilen, ob sie richtig sind. 



8.5 Wiederholung 

• Die Erzeugung originärer Daten verantwortet der Benutzer persönlich im Rah- 
men der maschinell überprüften Integritätsbedingungen. 

• Die Datenverantwortung trägt als Institution die Organisationseinheit, der der 
Benutzer angehört. Diese Einheit verantwortet die Korrektheit und Pünktlichkeit 
der zugewiesenen originären Daten gegenüber dem Unternehmen. 

• Die Datenverantwortung wird technisch über die Zuweisung von Zugriffsrechten 
durchgesetzt. Diese wirken auf den individuellen Benutzer, auch im Sinne des 
Datenschutzes im Unternehmen. 

• Die Festlegung der Datenverantwortung ist bei Grunddaten schwieriger als bei 
Vorgangsdaten; besonders problematisch beim Grundobjekttyp Teil. Dieser be- 
nötigt eine Prozessverantwortung im Rahmen der Produktentwicklung. 
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Vor allem die Grunddaten Teil entstehen in einem funktionsUbergreifenden Pro- 
zess, der sinnvoller Weise als Workflow technisch unterstützt werden sollte. 

Die Datenverantwortung bei der Erzeugung von Vorgangsdaten ist unkritisch. 
Ohne die Daten wären die Routineprozesse unvollständig oder gar nicht existent. 
Abgeleitete Daten kennen keine Datenverantwortung, wohl aber eine Programm- 
verantwortung. Dies ist die Verantwortung für die Korrektheit der Programme. 




9 



Die absehbare Zukunft: Grundideen von XML 



Mit XML wird ein bereits heute prominenter Vertreter der sog. Auszeichnungsspra- 
chen ausgewählt, bei denen Daten und deren Beschreibungen sich mischen. Aus- 
zeichnungssprachen haben ein völlig anderes Konzept von Daten als die relationa- 
le Welt, aber auch Gemeinsamkeiten. Wir besprechen die drei Einsatzgebiete von 
XML, ohne einen „Lehrgang“ in die Sprache liefern zu wollen: 

o Die Formulierung von strukturierten Daten zwecks einfacher Kommunikation, 
o Die Behandlung semistrukturierter Daten mit einem zu archivierenden Layout, 
o Die Abbildung der Struktur von Dokumenten. 



9.1 Einführung 

In Kapitel 3 waren unstrukturierte Daten von der Betrachtung in den Folgekapiteln 
ausgeschlossen worden. Nun wollen wir auf sie eingehen, da die technische Ent- 
wicklung es inzwischen erlaubt, in die Struktur von Texten besser „hineinzusehen“ 
oder auf Datentypen basierende Daten mit textorientierten Mitteln zu beschreiben 
und zu verarbeiten. Besonders in der zwischenbetrieblichen Kommunikation spielt 
diese Technologie eine bedeutende Rolle. Dort löst im Bereich der schon mehrfach 
erwähnten Norm EDIFACT die Sprache XML (Extensible Markup Language) die 
schwer verständliche ursprüngliche Sprache der EDI-Normfamilie ab (Beispiele s. 
Spitta, 2005). 

Die zunehmende Bedeutung von XML darf nicht so interpretiert werden, dass die 
Speicherung von Daten in strukturierter Form in absehbarer Zukunft obsolet werden 
wird. Im Gegenteil, man muss die Lehre von den Datentypen aus Kapitel 3 beherr- 
schen, um die Möglichkeiten, die sich hinter XML verbergen, in ihrer Tragweite zu 
verstehen. 

XML ist wie die früher populär gewordene Sprache HTML {Hypertext Markup 
Language) eine sog. Auszeichnungssprache . Mit solchen Sprachen werden text- 
orientierte Standards umgesetzt, indem Befehle in Texte geschrieben werden, die 
entweder das Layout des Textes (HTML) oder dessen Inhalt und logische Struktur 
(XML) bestimmen. 
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Vermutlich werden viele Leser wissen, dass die Texte des Internet in HTML darge- 
stellt sind. HTML enthält auch Befehle, um Dateien anderer Formate (Bilder, Tö- 
ne) einzubinden oder auf weitere Textdateien zu verweisen (sog. Links). Programme 
des Typs Browser stellen das Ganze am Bildschirm dar und erlauben den Wechsel 
zwischen Seiten. Der Leser kann sich problemlos einen Eindruck von einer Aus- 
zeichnungssprache verschaffen, indem er in einem beliebigen Browser Ansicht 
— > Quell text anklickt. Auf diese Weise bekommt er einen Blick hinter die „Ku- 
lisse“ der grafischen Oberfläche. 

Beide Sprachen sind Untermengen der seit den 80er Jahren bekannten universel- 
len Auszeichnungssprache SGML (Standard General Markup Language), die aller- 
dings als schwer handhabbar galt, lange Zeit nur Spezialisten bekannt war (Lobin, 
2000) und zum Zeitpunkt ihrer Definition noch zu viel Rechnerleistung erforderte. 
Sie stammt nicht aus der Informatik wie die Programmiersprachen, sondern aus der 
Linguistik. XML gilt als pragmatische Untermenge von SGML mit inzwischen vie- 
len praktischen Anwendungen (s. Möhr & Schmidt, 1999). 

Wir werden hier keinen Abriss von XML geben, wohl aber das grundlegende 
Prinzip aufzeigen, das man in Ergänzung des relationalen Speicher- und Benutzungs- 
konzeptes von Daten kennen sollte. Mit XML werden Anwendungsbereiche für un- 
strukturierte und schwach strukturierte Daten erschlossen, die bisher brach lagen 
oder einer immer noch sehr aufwändigen Volltextsuche Vorbehalten blieben. Aller- 
dings werden betriebliche Anwendungssysteme auf absehbare Zukunft auf relational 
strukturierten Daten aufbauen, die das Rückgrat der betrieblichen Ressource Daten 
bilden. 



9.2 Schemata 

Ein Schlüsselbegriff zum Verständnis von Daten ist das Wort Schema. Es kommt aus 
der Datenbanktechnik und bezeichnet ein Schichtenmodell von Beschreibungsebe- 
nen für Daten, bei dem jede Ebene von der darunter liegenden abstrahiert. „Oben“ 
steht für anwendungs- und benutzernah, „unten“ für techniknah. 

Im Datenbankbereich ist ein dreistufiges Modell üblich (Vossen, 2000, Kap. 1.2). 
Die oberste Schicht beschreibt Daten aus der Sicht der Anwendung (externes Sche- 
ma). Hinter ihr stehen Anwendungsprogramme oder Dialogbenutzer. Die mittlere 
Schicht (konzeptuelles Schema) abstrahiert von der Art der Speicherung, verlangt 
aber die Einhaltung bestimmter Regeln und gibt eine bestimmte Struktur vor. Beim 
relationalen Schema der mittleren Schicht sind dies die Tabelle als Grundstuktur und 
etwa das Verbot von Nullwerten in Eremdschlüsseln (vgl. Kap. 6). Das in der un- 
tersten Schicht liegende interne Schema verwaltet die Technik der physikalischen 
Speicherung auf Datenträgern und verbirgt die Eigenschaften der Datenträger vor 
den darüber liegenden Ebenen. Änderungen unterer Ebenen sollen sich auf darüber 
liegende nicht auswirken. So dürfen Anwendungsprogramme, die auf dem externen 
Schema aufsetzen, nicht beeinträchtigt werden, wenn der Rechnertyp oder das Da- 
tenbanksystem sich ändern. 
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Zu Schema gibt es auch einen übergeordneten Begriff, der allgemeiner formu- 
liert ist: Metadaten. Dies sind Daten über Daten. Für die Werte (zweifellos Daten), 
benötigt man deren allgemeinere Beschreibung, den Typ. Typen sind Metadaten. Wir 
bleiben jedoch beim Begriff Schema, da nur er gegenüber Metadaten ein Schichten- 
modell impliziert. 

Das Relationenmodell ist ein konzeptuelles Schema, über das wir nur wissen 
müssen, welche elementaren Datentypen erlaubt sind und welche Eigenschaften Pri- 
märschlüssel haben müssen (Eindeutigkeit). Darauf kann ein externes Schema auf- 
setzen und z.B. logische Sichten (views) auf Tabellen des konzeptuellen Schemas 
erlauben. Wie dies technisch geschieht, braucht den Benutzer der View nicht zu 
kümmern. Zur Verdeutlichung ein Beispiel in Tabelle 9.1. Programme, die nur den 
Artikelpreis benötigen, greifen auf der Ebene des externen Schemas mit einer Sicht 
(View) auf die konzeptuelle Tabelle zu. Wenn diese sich ändert, weil etwa ein Attri- 
but ergänzt wird, sind die Programme mit der View auf das Attribut Preis nicht 
betroffen. Die View abstrahiert von der Ebene Tabelle. 



Tabelle 9.1. Beispiel für eine View 



Schema Name 

externes view 

konzeptuelles table 



Beispiel 

ArtPreis ( ArtikelNr# , 
Artikel ( ArtikelNr# , 



Preis) 

Bezeichnung , 



Dimension, 



Preis) 



Die View hat einen anderen Namen als die Tabelle, greift aber auf sie mit deren 
Schlüssel zu. Die Sprache SQL, die hier nicht weiter behandelt wird, deckt beide 
Ebenen der Tabelle 9.1 ab. 

In Schichten angeordnete Schemata sind auch in anderen Gebieten der Informa- 
tionstechnik üblich, ohne so genannt zu werden. Statt von Schema spricht man von 
Schichtenmodellen, meint aber das gleiche Prinzip. Bekannte Schichtenmodelle sind 
das siebenstufige OSTModell {open Systems interconnection), das Protokolle der Da- 
tenübertragung regelt oder dessen Vereinfachung, die TCP/IP -Protokollfamilie, auf 
der das Internet basiert. Einzelheiten zu diesem Thema können bei Hansen & Neu- 
mann (2005, Bd 2, Kap. 6) nachgelesen werden. Auch die Datendeklarationen jeder 
Programmiersprache sind Schemata. 

Eür jede Ebene regelt ein Schema, wie sie definiert ist und welche Aufgaben sie 
wahrnimmt. Schemata (Schichtenmodelle) dienen der Komplexitätsreduktion durch 
Aufgabenverteilung auf die einzelnen Ebenen. Ein Schema enthält also Vorschriften 
für die Strukturierung und Interpretation von Daten. Mit Datentypen wird festge- 
legt, wie wir codierte Daten sehen und typgerecht verarbeiten wollen. Zahl-Zeichen 
werden nicht addiert, Zahlen schon. Also ist das Zeichen ’ 1’ von der Zahl 1 zu un- 
terscheiden. Alle Zeichenketten des verwendeten Alphabets müssen sich einem der 
vereinbarten Typen zuordnen lassen. So wird in der Sprache XML ursprünglich das 
primitivste Typkonzept verwendet, das man sich vorstellen kann. Die sog. DTD {Do- 
cument Type Definition) kennt nur einen einzigen Typ, und zwar string. DTD ist sehr 
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verbreitet, weil das eigentliche Schema von XML erst 2001 veröffentlicht wurde, gilt 
aber als Fehlentwicklung (Abiteboul, Bubemann & Suciu, 2000, 44). 

Mit XML kann man Datentypen und damit auch strukturierte Daten beschrei- 
ben, obwohl dies nicht die Kernidee von XML war (Kazakos, Schmidt & Tomczyk, 
2002). Für diesen Teilbereich des sehr großen Anwendungsspektrums von XML gibt 
es eine Komponente XML-Schema. XML-Schema hat etwa die gleichen Aufgaben 
und Möglichkeiten, wie eine Beschreibungsnorm aus dem relationalen Bereich, ist 
nur syntaktisch völlig anders gestaltet. Man kann relationale Schemata maschinell 
in XML-Schemata überführen. Es gibt also zwischen einem relationalen und einem 
XML-Schema keinen konzeptionellen Unterschied. Allein wegen „XML-Schema“ 
wäre das Thema XML in diesem Buch auch nicht der Rede wert. Es gibt jedoch einen 
sehr grundlegenden konzeptionellen Unterschied zwischen der relationalen Welt ei- 
nerseits und der textbasierten (XML-)Welt andererseits, den man nur verstehen kann, 
wenn man weiß, was ein Schema ist. Von diesem Unterschied soll jetzt die Rede sein. 



9.3 Kommunikation mit strukturierten Daten 

Der Unterschied zwischen den beiden Welten relationale und textbasierte Daten ist 
gravierend und wird vor allem bei der Kommunikation des Unternehmens mit seiner 
Umwelt wirksam. Das Unternehmen will mit externen Akteuren automatisiert Daten 
austauschen, also Kunden, Lieferanten, Behörden (Finanzamt) und Banken. 

9.3.1 Konzepte relationaler und textbasierter Daten 

Abb. 9.1 zeigt eine Kommunikationssituation zwischen zwei Akteuren des Wirt- 
schaftslebens. Man nennt diesen Fall B2B (Business to Business). Die Kommuni- 
kation B2C oder (Business to Consumer) umgekehrt ist strukturell gleich, allerdings 
aus Gründen des Verhaltens von Verbrauchern erheblich aufwändiger als B2B. 




Abb. 9.1. Automatische Datenübertragung zwischen zwei Unternehmen 



Die Akteure betreiben Computer zur Verarbeitung ihrer Daten, von denen man 
keineswegs annehmen darf, dass sie hinsichtlich Betriebssystem, Datenbanksystem 
und Anwendungssystemen gleich sind, im Gegenteil. Dasselbe Datenbanksystem 
speichert gelegentlich auf der technischen Ebene sogar die Daten verschiedener Ver- 
sionen unterschiedlich. Das haben Benutzer der PC-Datenbank MS-Access innerhalb 
weniger Jahre mehrmals erlebt. 
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Das Schema (alle drei Ebenen) wird in einem Computer getrennt von den Da- 
ten gespeichert. Zumindest die unterste Ebene ist bei allen Datenbanksystemen ver- 
schieden. Die Daten können aber nur verarbeitet werden, wenn dem verarbeitenden 
Programm das interne (technische) Schema zur Verfügung steht. 



Sender 


Daten 


Empfänger 


1 Schema A| 


1 Schema B| 




1 Daten A | 


1 Daten A 7 



Abb. 9.2. Verarbeitung und Übertragung von Daten zwischen relationalen Systemen 



Selbst das konzeptuelle Schema differiert zwischen verschiedenen Datenbank- 
systemen, wenn auch nur in Details. Es gibt für die eigentlich genormte Sprache 
SQL bei allen Herstellern leichte Unterschiede. Deshalb ist es auf einfache Weise 
nicht möglich, von einem relationalen System A geschriebene Daten mit einem an- 
deren System B zu lesen. Das konzeptuelle und das interne Schema muss zwischen 
Sender und Empfänger übereinstimmen, wenn dies gelingen soll. Dies zeigt Abb. 
9.2. Die relationale oder andere Speicherungen in Datenbanken sind erforderlich, da 
die internen Datenvolumina von Unternehmen oft groß sind und für die betrieblichen 
Anwendungssysteme nur eine Datenbank oder ein ähnliches System diese effizient 
verarbeiten kann. 

Das Konzept textorientierter Daten, die mit XML strukturiert sind, ist dagegen 
ein völlig anderes: 

o Die Daten sind in genormten Codes gespeichert, die von jedem Empfänger mit 
einem beliebigen Rechnersystem gelesen werden können, 
o Das Schema ist in den Daten enthalten und nicht getrennt von ihnen gespeichert. 
Es kann also bei jeder Kommunikation mit übertragen oder an einer beiden Ak- 
teuren zugänglichen Stelle hinterlegt werden, etwa im Internet. 



Sender: 




XML-Daten 


Schema + Daten 


erzeugen 




/ 





Empfänger: 
. XML-Daten 
lesen 



Abb. 9.3. Übertragung von Daten zwischen textbasierten Systemen 



XML hat im Gegensatz zu HTML die Eigenschaft, dass man damit Datenstruk- 
turen selbst definieren kann, wie wir es in Kapitel 3 kennen gelernt haben. Das ist 
genau die Eigenschaft einer Sprache, die man bei der automatisierten Kommunika- 
tion benötigt. Da XML ein Standard ist, kann der Empfänger die für ihn lesbaren 
Daten genau so interpretieren, wie der Sender sie verstanden hat. Abb. 9.3 zeigt dies. 
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Abb. 9.4. Zusammenhang zwischen Anwendungssystemen und Datenaustauschformat 



Die Kommunikation ist mit textbasierten Daten erheblich einfacher und damit 
wirtschaftlicher als mit Daten einer Datenbank. Abb. 9.4 zeigt den Zusammenhang 
zwischen dem Anwendungssystem Vertrieb, in dem der Baustein Fakturierung die 
Rechnung im relationalen (internen) Format und die Übertragungsdaten im (exter- 
nen) XML-Format durch einen Konverter erzeugt werden. Der Empfänger konver- 
tiert im Beispiel Abb. 9. 1 die XML-Rechnungen des Senders in sein eigenes internes 
Format für Lieferantenrechnungen. Der nächste Abschnitt bringt einige Beispiele 
in XML, die die bisherigen Ausführungen über die Sprache XML nachvollziehbar 
machen. 

9.3.2 Beispiele strukturierter Daten in XML 

Die folgenden Beispiele wurden ausgearbeitet von Stefan Tüllmann (2005). Abb. 9.5 
zeigt ein erstes XML-Beispiel für eine Rechnung. Abgebildet wird das relationale 
Schema 

Rechnung ( RechnungsNr# , Lieferdatum, ArtikelNr#, Artikel - 
bezeichnung, Stückzahl, Mengeneinheit, Rechnungsbe- 
trag, Währung, Zahlungsziel) 

einer sehr einfachen Rechnung ohne separate Position, da nur ein Artikel geliefert 
wird. Zur Information wird dem Kunden natürlich auch die Artikelbezeichnung aus 
dem GOT Artikel dargestellt, so dass die Relation als abgeleitete View nicht der 
3NF genügt, dies aber auch nicht muss. 

Zunächst vermittelt jedes XML-Dokument, mit welcher XML- Version und wel- 
chem Code es gelesen werden muss (s. Abb. 9.5). Die im Text in spitzen Klammern 
eingefassten Namen heißen Tags. Das Wort Tag bedeutet im Englischen Schildchen. 
Die Schildchen zeichnen einen Teil des Textes aus, sind also Metadaten. Der Inhalt 
ist im Eall 

<Rechnungsbetrag>5000</Rechnungsbetragxwährung>Euro</Währung> 

die Auszeichnung eines Rechnungsbetrages von 5.000 Einheiten der Währung Euro. 

Dem gegenüber sind in HTML die Tags nicht frei wählbar, sondern vorgegeben 
und bezeichnen nicht den Inhalt, sondern die Form des Inhaltes oder der Darstellung. 
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<?xml version="l . 0" encoding="iso- 8859 "> 

<Rechnung> 

<RechnungsNr>2 32 5 </RechnungsNr> 

<Lief erDatum>2 0 . 03 . 2005</Lief erDatum> 
<ArtikelNr>8003567</ArtikelNr> 

<Ar t ikelBez ei chng> Schmier Stoff SuperOil</ArtikelBezeichng> 
<Stückzahl>1000</ Stückzahl> 

<MengenE i nhe i t >kg< / MengenE i nhe i t > 
<RechnungsBetrag>5000</RechnungsBetrag> 
<Währung>Euro</Währung> . 

<Zahlungsziel>14 .04.2005. </Zahlungsziel> 

</Rechnung> 



Abb. 9.5. Eine Rechnung, formuliert in XML 



Wir sehen, gerade auch im Vergleich mit der Relation, dass sich mit XML ge- 
nauso Datenstrukturen beschreiben lassen wie mit dem Relationenmodell und dass 
in beiden Notationen keine Beschreibungen der elementaren Datentypen vorgesehen 
sind. Sie kommen in XML erst mit XML-Schema und in der relationalen Welt mit 
der hier nicht behandelten Sprache SQL (s. Fanny & Taudes, 2000) hinzu. Wir hat- 
ten in Kapitel 6, Seite 92 vereinfachend die Datentypen in der Kopfzeile der Tabellen 
untergebracht, um die komplizierte SQL-Syntax zu vermeiden. 

Soweit die konzeptionellen Überdeckungen. Viel entscheidender sind jedoch die 
Unterschiede. In Abb. 9.5 ist unschwer zu sehen, wie die Daten mit dem Schema 
zusammen transportiert werden, wie also Abb. 9.4 in XML umgesetzt wird. 



Tabelle 9.2. Zwei Belege und zwei Buchungen relational 



Beleg 

Beleg# 


BelegDat 


Buchung 

BuchungsNr# 


BuchungsDat 


Buchungstext 


Beleg# 


5 


16.03.2005 


1 


01.04.2005 


Eingangsrechnung 


5 


7 


24.03.2005 


2 


01.04.2005 


Eingangsrechnung 


7 



Dies wird durch ein zweites Beispiel in Tabelle 9.2 noch deutlicher. Sie zeigt 
ein Beispiel aus der Buchhaltung mit zwei Belegen, die gebucht werden (s. auch 
Abschnitt 5.5.1). 

Jede Tabelle enthält zwei Zeilen. Abb. 9.6 zeigt im XML-Format, dass jeder Da- 
tenwert aus jeder Zeile für sich jeweils neu ausgezeichnet wird. Würden nur die Da- 
ten transportiert (s. Abb. 9.2), wären nur ein Bruchteil an Zeichen gegenüber XML 
zu übertragen. Das könnte in textcodierter Form mit als Trennzeichen zwischen 
den Werten der Attribute, so aussehen: 
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5, • 16. 03. 2005;7; 24. 03. 2005;!, "Ol. 04. 2005; Eingangsrechnung; 5 ; ... 



Dies kann aber nur lesen, wer das Schema hat. Ohne Metadaten kann man die 
Werte nicht verstehen. 



<Tabelle Beleg> 

<Zeile> 

<Beleg>5</Beleg> 

<BelegDatum>16 . 03 . 2005</BelegDatum> 

</Zeile> 

<Zeile> 

<Beleg>7</Beleg> 

<BelegDatum>24 . 03 . 2005</BelegDatum> 

</Zeile> 

</Tabelle Beleg> <Tabelle Buchung> 

<Zeile> 

<BuchungsNr>K/BuchungsNr> 

<Beleg>5</Beleg> 

<BuchungsDatum>l . 4 . 2005</BuchungsDatum> 
<BuchungsText>Eingangsrechnung</BuchungsText> 
</Zeile> 

<Zeile> 

<BuchungsNr>2</BuchungsNr> 

<Beleg>7</Beleg> 

<BuchungsDatum>l . 4 . 2005</BuchungsDatum> 
<BuchungsText>Eingangsrechnung</BuchungsText> 
</Zeile> 

</Tabelle Buchung> 



Abb. 9.6. Die Buchungen aus den Tabellen 9.2, formuliert in XML 



Der „Preis“ für die Verwendung von XML ist also hoch, allerdings auch der 
Nutzen. Da die Übertragung auch vieler zeichenorientierter Daten heute billig und 
technisch schnell genug ist, hat man als Nutzen erhöhte betriebliche Flexibilität und 
auch geringere organisatorische Transaktionskosten. Abstimmungen über Schemata 
sind fehleranfällig, kosten Personalkapazität und Software für Datenkonvertierun- 
gen. Außerdem gibt es Techniken, den Anteil der übertragenen Metadaten zu verrin- 
gern, unter anderem durch das im nächsten Abschnitt behandelte XML-Schema. 

Offen ist noch ein letzter Punkt: Der Strukturunterschied zwischen dem Rela- 
tionenmodell und XML. Das RM erlaubt gemäß der INF nur einstufige, XML aber 
beliebig tief geschachtelte Flierarchien. Aus diesem Grund ist es nicht trivial, teil- 
weise auch unmöglich, beliebige XML-Strukturen in das RM zu überführen. 

Damit dürften die Grundprinzipien von XML bezüglich der Übertragung struk- 
turierter Daten deutlich geworden sein. Es bleibt XML-Schema. 
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9.3.3 XML-Schema 

XML-Schema ist als Mittel für Typdefinitionen schon erwähnt worden. Jetzt soll 
an Hand eines Beispiels gezeigt werden, wie es aussieht und gehandhabt werden 
kann. Wir sehen in Abb. 9.7 zunächst, dass alle Tags mit dem Erkennungsstring ’xs’ 
beginnen und dass keine Daten enthalten sind. Es handelt sich um die Relation 

Kreditor ( KreditorNr# , Name, PLZ, Ort). 



<xs:element name="Kreditor"> 

<xs : complexType> 

<xs : sequence> 

<xs:element name=" KreditorNr" type="xs : integer" /> 
<xs:element name="Name" type="xs : String" /> 
<xs:element name="PLZ" type="xs : integer" /> 
<xs:element name="Ort" type="xs : String" /> 

</xs : sequence> 

</xs : complexType> 

<xs : key> 

<xs:Field xPath ="KreditorNr"> 

</xs :key> 

</xs : element 



Abb. 9.7. Beispiel für Typdefinitionen in XML-Schema 



Es wird das Schema eines zusammengesetzten Datentyps dargestellt, hier com- 
plexType genannt. Die Tag-Bezeichnung sequence lässt vermuten, dass es andere 
Strukturen gibt als die Sequenz. Die elementaren Datentypen haben einen Namen 
und einen Typ. In Hansen & Neumann (2005, Bd 2, Abschn. 5. 4. 1.2)) können weitere 
Einzelheiten nachgelesen werden, etwa dass alle üblichen oder auch viele pragma- 
tisch nützliche Basistypen existieren und dass Integritätsbedingungen formulierbar 
sind. Es gibt sogar ein Konstrukt, um ein (oder mehrere, hier nicht gezeigt) Elemente 
als Schlüssel zu kennzeichnen. Auf die Abfragesprache XPath aus der XML-Eamilie 
können wir hier nicht eingehen. Sie wird im Beispiel Abb. 9.7 bei der Definition des 
Schlüssels erwähnt. 

Das Schema kann entweder einer Datenübertragung mitgegeben werden, dann 
dient es eher der Information des Empfängers. Der Sender konnte seine Nachricht 
ja bereits an Hand des Schemas auf Typkonformität überprüfen, entlastet also den 
Empfänger von Prüfarbeit. Das Schema kann aber auch bei einem Provider, abgesi- 
chert gegen Veränderungen, im Internet hinterlegt sein. Auf diese Weise lassen sich 
Standards durchsetzen, die die Akteure nicht verändern können. Das wäre mit XML 
ohne ein Schema nicht möglich. Hierin liegt der eigentliche Wert von Datentypen, 
deren Schema kommuniziert wird. 
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Eine andere Stärke von XML besteht darin, Texte und strukturierte Daten zu 
mischen. Von diesen semistrukturierten Daten soll im nächsten Abschnitt die Rede 
sein. 

Zusammenfassung Abschnitt 9.3 

o Relationale Daten sind zur Kommunikation mit der Umwelt des Unter- 
nehmens schlecht geeignet. 

o Textorientierte Daten eignen sich genau hierzu besonders gut, weil sie 

- in genormten Codes vorliegen, also lesbar sind, 

- Inhalt und Schema der Daten enthalten. 

o Relationale Schemata lassen sich leicht nach XML konvertieren. Die 
Umkehrung gilt wegen der Strukturunterschiede in der Hierarchie nicht. 
o XML-Schema entspricht in den Ausdrucksmöglichkeiten der relationa- 
len Welt. 



9.4 Semistrukturierte Daten 

Die Spanne „halb“-strukturierter Daten reicht von überwiegend strukturierten Daten, 
in die ein wenig Text eingestreut werden soll, bis zum unstrukturierten Text, der 
einige strukturierte Attribute enthält. 

9.4.1 Das Konzept 

Schon „immer“ (seit etwa 1970) gab es Texte, die auch variable Daten enthalten. 
Das Konzept des Serienbriefes aus Office-Systemen ist der Versuch, damit umzu- 
gehen. Office-Systeme, etwa MS-Ofßce oder OpenOfßce, kennen Datenelemente in 
den Texten, z.B. für Serienbriefe. Die Schwierigkeit ist jedoch, dass die Daten und 
die Art ihrer Verarbeitung vollkommen herstellerspezifisch und evtl, ohne das Pro- 
gramm in der „richtigen“ Version nicht lesbar^ sind. Bei der Kommunikation mit 
Daten aus Office-Systemen haben wir dieselbe Situation wie mit relationalen Daten, 
die in Abb. 9.2 dargestellt wurde. 

Mit XML ist dies jedoch problemlos möglich. Man kann neben strukturierten, 
mit Tags ausgezeichneten Daten auch Texte in eine XML-Datei einstreuen, wie Abb. 
9.8 im folgenden Abschnitt am Beispiel der uns schon bekannten Rechnung zeigt. 
Dies hat eine große wirtschaftliche Bedeutung, die über die Möglichkeiten von Text- 
komponenten der Office-Systeme weit hinaus reicht. 

Wir hatten in Kapitel 5 von aufzeichnungspflichtigen Daten gesprochen. Das 
HOB geht aber noch weiter und schreibt die Aufbewahrung von Dokumenten vor 
(§ 257). Dies sind alle Schriftstücke, die das Unternehmen von außen im Rahmen 

* Immerhin sind die Texte von OpenOffice in XML abgebildet, also lesbar. Das Lesepro- 
gramm ist Jedoch der Baustein OpenOfßce Weiter, ohne den das Lesen sehr schwierig wer- 
den dürfte. Näheres s. www. OpenOffice . org 
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von Handelsgeschäften erreichen. Dies zog nicht selten gewaltige Aktenarchive nach 
sich, denn das Gesetz schreibt eine zehnjährige Aufbewahrung vor. In Zeiten billiger 
optischer Speicher wie CD und DVD muss dies zwar nicht mehr sein, ist aber mit 
Scannen und Speichern allein nicht erledigt. Die gespeicherten Dokumente enthal- 
ten Daten, deren Bezug zu den in den Vorgangsdaten abgelegten Geschäftsvorfällen 
kurzfristig, also maschinell herstellbar sein muss. Also müssen die Daten in den Tex- 
ten erkenn- und auswertbar sein. 

Werden die Dokumente als Bilder (= eingescanntes Papier) gespeichert, müs- 
sen sie kurzfristig in der empfangenen Form, also bildlich identisch zum Orignal, 
verfügbar gemacht werden können (§ 257(3) Nr.l HGB). Dies ist mit relationalen 
Datenbeständen nicht möglich, im Gegenteil. Die relationale Speicherung von Da- 
ten hat sogar zum Ziel, von der Art der Ausgabe auf Bildschirme oder Drucker zu 
abstrahieren, also vom Bild eines Dokuments. Hier liegt eine der großen Stärken von 
XML. Die Sprache kann Texte und Daten gemischt speichern und mit einem Zusatz 
aus der XML-Sprachfamilie, XSL (Extensible Style Sheet Language), auch das Lay- 
out eines Dokuments abbilden. Dies ist es, was der Gesetzgeber verlangt:^ Die Daten 
sind elektronisch erkennbar und das gespeicherte Layout ist wieder herstellbar. 

Ebenso ist es möglich, das Dokument nur elektronisch zu versenden, wie in 
Abschnitt 9.3 für reine Daten dargestellt. Wenn Sender oder Empfänger das XML- 
Dokument drucken, erhalten sie das gleiche Layout, wie vom Gesetzgeber gefordert. 

Dem gegenüber sind Bildarchive nur ein schlechter und teurer Behelf für das Ar- 
chivierungsproblem. Es ist auf einfache Weise nicht möglich, in Bilddaten einzelne 
Elemente als codierte Daten zu kennzeichnen. Man muss also neben dem Bildarchiv 
codierte oder relationale Metadaten halten. 

Wir zeigen jetzt ein einfaches Beispiel, allerdings ohne eine Layout-Komponente. 

9.4.2 Beispiel 

Abb. 9.8 zeigt die uns schon bekannte Rechnung aus Abb. 9.5, erweitert um einige 
Textelemente. Man sieht, dass sich Text von Daten dadurch unterscheidet, dass er 
nicht ausgezeichnet ist. Die Mischung zwischen Daten und Text ist beliebig. Es ist 
also durchaus möglich und in großen Firmen bereits üblich, wichtige textorientierte 
Dokumente, die nur einige Daten enthalten, in XML abzubilden. Dies geschieht z.B. 
mit dem Geschäftsbericht der SAP AG.^ 

Die Möglichkeit, Abb. 9.8 mit Hilfe von XSL in ein Dokumenten-Layout zu brin- 
gen, würde hier zu viele technische Erklärungen erfordern. Der Leser wird glauben, 
dass dies möglich ist, wenn er sich auch nur einige der vielen Millionen Internetsei- 
ten ansieht, bei denen dies sogar mit dem viel primitiveren HTML gelingt. 

Wichtiger für den Zweck dieses Buches ist, noch kurz die Erage zu klären, wozu 
denn XML gebraucht wird, um reine Texte zu behandeln, die keine strukturierten 
Daten enthalten. 

^ Seit 2002 gibt es ein XML-Schema der Finanzbehörden, mittels dessen automatische Buch- 
prüfungen durchgeführt werden. Die Regeln hierfür sind in der GDPdU {Grundsätze zum 
Datenzugriffund zur Prüfbarkeit digitaler Unterlagen) niedergelegt. 

^ z.B. WWW. sap - ag . com/ Company/ investor/2 003/ index . epx 
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<?xml version=" 1 . 0 " encoding="iso- 8859 "> 

<Rechnung> 

Rechnung : <RechnungsNr>2 32 5 </RechnungsNr> 

Wir bedanken uns für Ihren Auftrag vom 

<Auf tragsDatum>20 . 03 . 2005</Auf tragsDatum> und berechnen 
Ihnen : 

<Stückzahl>1000</Stückzahl> 

<MengenEinheit>kg</MengenEinhei t> 
<ArtikelNr>8003567</ArtikelNr> 

<Ar t ikelBez ei chng> Schmier Stoff SuperOil</ArtikelBezeichng> 
<RechnungsBetrag>5000</RechnungsBetrag> Euro . 

Die Rechnung ist zahlbar bis zum 
<Zahlungsziel>14 . 04 . 2005</Zahlungsziel> ohne Abzüge. 
Hamburg, den <RechnungsDatum>01 . 04 . 2005</RechnungsDatum> . 
</Rechnung> 



Abb. 9.8. Eine textorientierte Rechnung mit XML 



Zusammenfassung Abschnitt 9.4 

o In der problemlosen Behandlung semistmkturierter Daten liegt die ei- 
gentliche Stärke von XML. Dem gegenüber haben relationale Systeme 
ihre Stärken in der Geschwindigkeit des Zugriffs, 
o XML erlaubt die Darstellung, Speicherung und Übermittlung von Lay- 
outs im Verbund mit strukturierten Daten. 



9.5 Dokumente 

Wir haben bisher den Begriff Dokument nicht weiter hinterfragt, der für unstruk- 
turierte Daten schlechthin steht. Jeder Roman, Zeitungsartikel, Geschäftsbrief, auch 
jede Internet-Seite, ist ein Dokument. Schon intuitiv wird man hinter Dokument mehr 
vermuten als hinter unserer bisher größten Einheit von Zeichenfolgen, dem Text (vgl. 
Abschnitt 3.1). Eine E-Mail oder SMS werden wir eher nicht als Dokument betrach- 
ten, sondern nur als Text. Dokumente unterscheiden sich von einfachen Texten durch 
eine explizit sichtbare Struktur, die eine Orientierung bietet. Doch welche Dokumen- 
te sind hier wichtig und welche Rolle kann XML in diesem Zusammenhang spielen? 

Während in einem Geschäftsbericht noch ein nicht unerheblicher Teil an struk- 
turierten Daten enthalten ist, gibt es auch im Industrieunternehmen wichtige Doku- 
mente, die auf den ersten Blick „nur“ Texte sind. Beispiele sind: 

o Organisationsanweisungen 
o Notfall- oder Datenschutzhandbücher 
o Verträge mit Lieferanten oder Kunden 
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o Handbücher von Produkten. 

Wir beschränken unsere Diskussion auf das letzte Beispiel, das nicht zufällig 
dieselbe Nachsilbe hat wie das Objekt, das der Leser in der Hand hält. 

Zu jeder komplexen technischen Anlage (z.B. Chemieanlage, Zeitungsdruckmaschi- 
ne) gehört mindestens ein technisches Handbuch. Man kann es keinesfalls dem Kun- 
den auf CD-ROM oder Internet-Link ausliefern mit dem Hinweis „drucken können 
Sie ja selbst“. Wer Millionen für ein Produkt bezahlt, erwartet als Teilprodukt ei- 
ne professionell gegliederte, geschriebene und gedruckte Beschreibung. Zusätzlich 
wird der Kunde das „Buch“ auch am Bildschirm lesbar geliefert haben wollen. 

Bei einem gedruckten Buch liefert die Gliederung die Struktur, bestimmte Ver- 
zeichnisse helfen bei der Suche nach Begriffen, Bildern oder Tabellen. Liegt ein 
Text online vor, kann man selbst mit einer Textverarbeitung nach jeder denkbaren 
Zeichenkette suchen. Diese einfache Technik nennt man Volltextsuche. Damit wird 
der Benutzer eines industriellen Handbuchs allerdings nicht zufrieden sein. Auch 
wird ein Handbuch nicht für jedes Exemplar einer Produktserie neu erstellt, selbst 
wenn jedes Produkt kundenindividuell ausgestaltet ist. Man wird das Dokument in 
selbständige Bausteine zerlegen und das Handbuch für jede Kundenversion nur zu- 
sammenstellen und ggf. ergänzen. Damit das handhabbar ist, müssen die Bausteine 
und ihre Struktur mit Metadaten beschrieben sein. Dies lässt sich mit einem Office- 
System nicht mit vertretbarem Aufwand durchführen, ganz zu schweigen von her- 
stellerspezifischen Codes einiger Systeme. 

Beim industriellen Handbuch wie auch beim verkauften Buch lässt sich die von 
allen Exemplaren einzuhaltende Struktur mit XML-Schema festlegen, so dass jede 
Ausprägung genau der vorgegebenen Struktur entspricht. Hansen & Neumann (2005, 
Bd.2, 477) zeigen ein Beispiel für eine ähnliche Problemstellung, eine Buchbestel- 
lung. Ein konkretes Exemplar zeigt Abb. 9.9 für das vorliegende Buch, allerdings 
nur sehr skizzenhaft angedeutet. 

Wir sehen die auch ohne XML auf dem Papier sichtbare Struktur. Bei der Ab- 
lage als Textdaten muss die Struktur jedoch ausgezeichnet sein, um sie anderweitig 
irgendwie zu verwerten. Soweit die Kennzeichnung einer vom Autor explizit ge- 
schaffenen Struktur. Es dürfte dem Leser jedoch klar geworden sein, dass mit XML 
mehr möglich ist. Es ist kein Problem, Teile eines Textes nachträglich auszuzeichnen 
und diese vorher unsichtbare Struktur dann auszuwerten, evtl, über alle bestehenden 
Dokumente. Hier gehen die flexiblen Mittel von XML weit über Textsysteme hin- 
aus, die mit dieser Technik schon seit langem Wörter für ein automatisch erstelltes 
Schlagwortverzeichnis kennzeichnen. 

Abschließend sei ein Blick auf eine andere Branche erlaubt. Während ein In- 
dustrieunternehmen im Regelfall eine überschaubare Anzahl von Verträgen haben 
wird, hat ein Versichungsunternehmen einige Hunderttausend. Hier bietet XML die 
Möglichkeit, durch nachträgliches Auszeichnen Licht in das Dunkel der Vertragsdo- 
kumente zu bringen, auch wenn der Aufwand nicht unerheblich ist. In jedem solchen 
Vertrag sind Daten verborgen, die es sichtbar zu machen gilt. 

Auch die Auftritte großer Institutionen im Internet (Eirmen, Ministerien, Uni- 
versitäten) sind sehr große Sammlungen von Dokumenten. Auch hier kann über die 
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<?xml version=" 1 . 0 " encoding="iso- 8859 "> 

<Buch> 

<Vorspann> 

<Titel>Informat ionswirt Schaf t</Titel> 

<Vorwort>Dieses Buch . . . </Vorwort> 
<Inhalt>Inhaltsverzeichnis . . .</lnhalt> 

<Abkürzungen>Abb . Abbildung . . . </Abkürzungen> 
</Vorspann> 

<Hauptteil> 

<Kapitel>Einführung</Kapitel> 

<Kapitel>Betriebliche Funktionen und Prozesse</Kapitel> 
<Abschnitt>Funktions - Sicht</Abschnitt> 

<UnterAbschn>Funktionaler Überblick</UnterAbschn> 

<Abschnitt>Prozess - Sicht</Abschnitt> 

<UnterAbschn>Prozesse und Funktionen</UnterAbschn> 

</Hauptteil> 

<Abschluss> 

<Literatur>Literaturverzeichnis . . . </Literatur> 
<Schlagwörter>Ablauf , 22 . . . </Schlagwörter> 

</Abschluss> 

</Buch> 



Abb. 9.9. Skizze der Struktur dieses Buches, ausgezeichnet mit XML 

Struktur der Dokumente und ausgewählte Inhalte mit XML ein Ein- und Überblick 
geschaffen werden. 

Damit nicht der Eindruck entsteht, XML und HTML seien die einzigen bedeutsamen 
Auszeichnungssprachen, folgen einige Bemerkungen zu einem sehr hochwertigen 
System zu Herstellung von Texten mit anspruchsvollem Layout. Das vorliegende 
Buch ist mit der Auszeichnungssprache TpX bzw. dem System HTjhX geschrieben 
(s. Kopka, 2000). Es ist seit 1978, also weit vor dem Auftauchen der ersten PC in 
Gebrauch. Es ist kostenlos und wird vor allem im wissenschaftlichen Bereich und für 
umfassende industrielle Handbücher eingesetzt. Der Leser möge selbst das Layout 
mit dem anderer Bücher vergleichen, die mit Office-Systemen erstellt sind. 

Zusammenfassung Abschnitt 9.5 

o Mit XML lassen sich auch die Struktur oder andere Mermale von Doku- 
menten vorgeben oder nachträglich auszeichnen, 
o Der große Unterschied von Auszeichnungssprachen für Texte gegenüber 
Office-Systemen ist die Unabhängigkeit der Daten vom Programm. Dies 
beruht auf den Standards der Auszeichnungen und der Codes. 
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9.6 Wiederholung 

• Daten sind nur interpretierbar, wenn man das Schema kennt. 

• Bei relationaler Speicherung von Daten sind in der Regel die Verarbeitungspro- 
gramme an das Schema der verwendeten Datenbank gebunden. 

• Bei textorientierter Speicherung mit XML ist das Schema in den Daten enthalten. 
Dies macht die Kommunikation über Rechnergrenzen sehr viel einfacher als bei 
relationalen Daten. 

• Mit XML-Schema gibt es ein Konzept, das dem relationalen Schema vergleichbar 
ist. 

• Die Stärken von XML liegen in der Übermittlung von Daten und in der beliebi- 
gen Mischung aus strukturierten Daten und Text. 

• Unstrukturierte Texte kann man im Nachhinein mit einer Auszeichnungssprache 
transparent machen {auszeichnen) und so Struktur oder Daten abfragbar machen. 
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